System for displaying medical monitoring data

ABSTRACT

A first medical device can receive a physiological parameter value from a second medical device. The second physiological parameter value may be formatted according to a protocol not used by the first medical device such that the first medical device is not able to process the second physiological parameter value to produce a displayable output value. The first medical device can pass the physiological parameter data from the first medical device to a separate translation module and receive translated parameter data from the translation module at the first medical device. The translated parameter data can be processed for display by the first medical device. The first medical device can output a value from the translated parameter data for display on the first medical device or an auxiliary device.

RELATED APPLICATIONS

This application is a non-provisional of U.S. Provisional ApplicationNo. 61/889,972, filed Oct. 11, 2013, titled “System for DisplayingMedical Monitoring Data,” and is also a continuation-in-part of U.S.application Ser. No. 13/651,167, filed Oct. 12, 2012, which is anon-provisional of each of the following U.S. Provisional PatentApplications:

Ser. No. Date Title 61/547,017, Oct. 13, 2011, Visual Correlation ofPhysiological Information, 61/547,577, Oct. 14, 2011, Visual Correlationof Physiological Information, 61/597,120, Feb. 9, 2012, VisualCorrelation of Physiological Information, 61/703,773, Sep. 20, 2012,Medical Monitoring Hub

All of the above applications are incorporated by reference herein intheir entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to patient monitoring devicesand specifically to a patient monitor and medical data communicationhub.

BACKGROUND OF THE DISCLOSURE

Today's patient monitoring environments are crowded with sophisticatedand often electronic medical devices servicing a wide variety ofmonitoring and treatment endeavors for a given patient. Generally, manyif not all of the devices are from differing manufactures, and many maybe portable devices. The devices may not communicate with one anotherand each may include its own control, display, alarms, configurationsand the like. Complicating matters, caregivers often desire to associateall types of measurement and use data from these devices to a specificpatient. Thus, patient information entry often occurs at each device.Sometimes, the disparity in devices leads to a need to simply print andstore paper from each device in a patient's file for caregiver review.

The result of such device disparity is often a caregiver environmentscattered with multiple displays and alarms leading to a potentiallychaotic experience. Such chaos can be detrimental to the patient in manysituations including surgical environments where caregiver distractionis unwanted, and including recovery or monitoring environments wherepatient distraction or disturbance may be unwanted.

Various manufacturers produce multi-monitor devices or devices thatmodularly expand to increase the variety of monitoring or treatmentendeavors a particular system can accomplish. However, as medical devicetechnology expands, such multi-monitor devices begin to be obsolete themoment they are installed.

SUMMARY

This disclosure describes embodiments of a medical monitoring hub as thecenter of monitoring for a monitored patient. The hub can includeconfigurable medical ports and serial ports for communicating with othermedical devices in the patient's proximity. Moreover, the hub cancommunicate with a portable patient monitor. The monitor, when dockedwith the hub, may provide display graphics different from when undocked.The display graphics can include anatomical information. The hub canassemble the often vast amount of electronic medical data, associate itwith the monitored patient, and in some embodiments, communicate thedata to the patient's medical records.

Some aspects of the disclosure describe a first medical device havingdigital logic circuitry receives a physiological signal associated witha patient from a physiological sensor, obtains a first physiologicalparameter value based on the physiological signal, and outputs the firstphysiological parameter value for display. The first medical device canalso receive a second physiological parameter value from a secondmedical device other than the first medical device, where the secondphysiological parameter value is formatted according to a protocol notused by the first medical device, such that the first medical device isnot able to process the second physiological parameter value to producea displayable output value. The first medical device can pass thephysiological parameter data from the first medical device to a separatetranslation module, receive translated parameter data from thetranslation module at the first medical device, where the translatedparameter data is able to be processed for display by the first medicaldevice, and output a second value from the translated parameter data fordisplay. The first medical device may be, for example, a monitoring hub,a portable physiological monitor, or a multi-patient monitoring system,and the second medical device may be an infusion pump, ventilator, orthe like.

For purposes of summarizing the disclosure, certain aspects, advantagesand novel features are discussed herein. It is to be understood that notnecessarily all such aspects, advantages or features will be embodied inany particular embodiment of the invention and an artisan wouldrecognize from the disclosure herein a myriad of combinations of suchaspects, advantages or features.

BRIEF DESCRIPTION OF THE DRAWINGS

The following drawings and the associated descriptions are provided toillustrate embodiments of the present disclosure and do not limit thescope of the claims.

FIGS. 1A-1C illustrate perspective views of an exemplary medicalmonitoring hub according to an embodiment of the disclosure. Forexample, FIG. 1A illustrates the hub with an exemplary docked portablepatient monitor, FIG. 1B illustrates the hub with a set of medical portsand a noninvasive blood pressure input, and FIG. 1C illustrates the hubwith various exemplary temperature sensors attached thereto, allaccording to various embodiments of the disclosure.

FIG. 2 illustrates a simplified block diagram of an exemplary monitoringenvironment including the hub of FIG. 1, according to an embodiment ofthe disclosure.

FIG. 3 illustrates a simplified exemplary hardware block diagram of thehub of FIG. 1, according to an embodiment of the disclosure.

FIG. 4 illustrates a perspective view of an exemplary removable dockingstation of the hub of FIG. 1, according to an embodiment of thedisclosure.

FIG. 5 illustrates a perspective view of exemplary portable patientmonitors undocked from the hub of FIG. 1, according to an embodiment ofthe disclosure. Moreover, FIG. 5 illustrates an exemplary alternativedocking station.

FIG. 6 illustrates a simplified block diagram of traditional patientdevice electrical isolation principles.

FIG. 7A illustrates a simplified block diagram of an exemplary optionalpatient device isolation system according to an embodiment of thedisclosure, while FIG. 7B adds exemplary optional non-isolation powerlevels for the system of FIG. 7A, also according to an embodiment of thedisclosure.

FIG. 8 illustrates a simplified exemplary universal medical connectorconfiguration process, according to an embodiment of the disclosure.

FIGS. 9A-9B, 10, 11A-11F, 11G1-11G2, and 11H-11K illustrate simplifiedblock diagrams of exemplary universal medical connectors having a sizeand shape smaller in cross section than tradition isolationrequirements.

FIG. 10 illustrates a perspective view of a side of the hub of FIG. 1,showing exemplary instrument-side channel inputs for exemplary universalmedical connectors, according to an embodiment of the disclosure.

FIGS. 11A-11F, 11G1-11G2, and 11H-11K illustrate various views ofexemplary male and mating female universal medical connectors, accordingto embodiments of the disclosure.

FIG. 12 illustrates a simplified block diagram of a channel system forthe hub of FIG. 1, according to an embodiment of the disclosure.

FIG. 13 illustrates an exemplary logical channel configuration,according to an embodiment of the disclosure.

FIG. 14 illustrates a simplified exemplary process for constructing acable and configuring a channel according to an embodiment of thedisclosure.

FIG. 15 illustrates a perspective view of the hub of FIG. 1, includingan exemplary attached board-in-cable to form an input channel, accordingto an embodiment of the disclosure.

FIG. 16 illustrates a perspective view of a back side of the hub of FIG.1, showing an exemplary instrument-side serial data inputs, according toan embodiment of the disclosure.

FIG. 17A illustrates an exemplary monitoring environment withcommunication through the serial data connections of FIG. 16, accordingto embodiments of the disclosure.

FIG. 17B illustrates an exemplary connectivity display of the hub ofFIG. 1, according to embodiments of the disclosure.

FIG. 18 illustrates a simplified exemplary patient data flow process,according to an embodiment of the disclosure.

FIGS. 19A-19J illustrate exemplary displays of anatomical graphics forthe portable patient monitor of FIG. 1 docked with the hub of FIG. 1,according to embodiments of the disclosure.

FIGS. 20A-20C illustrate exemplary displays of measurement data showingdata separation and data overlap on a display of the hub of FIG. 1,respectively, according embodiments of the disclosure.

FIGS. 21A and 21B illustrate exemplary displays of measurement datashowing data separation and data overlap on a display of the portablepatient monitor of FIG. 1, respectively, according embodiments of thedisclosure.

FIGS. 22A and 22B illustrate exemplary analog display indicia accordingto an embodiment of the disclosure.

FIGS. 23A-23F illustrate exemplary displays of measurement data showing,for example, data presentation in FIGS. 23A-23D when a depth ofconsciousness monitor is connected to a channel port of the hub of FIG.1, data presentation in FIG. 23E when temperature and blood pressuresensors communicate with the hub of FIG. 1 and data presentation in FIG.23F when an acoustic sensor is also communicating with the hub of FIG.1, according embodiments of the disclosure.

FIG. 24 illustrates another embodiment of a monitoring environmentincluding the hub of FIG. 1.

FIG. 25 illustrates an embodiment of a translation message handlingprocess.

FIGS. 26-39 and 46-71 illustrate additional example hub displays,including displays of measurement data.

FIG. 40A illustrates an example first medical device and an examplesecond medical device that communicate with one another via atranslation module.

FIG. 40B illustrates an example first medical device and an examplesecond medical device that communicate with one another via atranslation module and a communication bus.

FIG. 41A illustrates an example input message received by thetranslation module.

FIG. 41B illustrates an example message header segment of an inputmessage that has been parsed into fields.

FIG. 41C illustrates an example encoded version of the parsed messageheader segment of FIG. 41B.

FIG. 41D illustrates an example output message of the translation modulebased on the input message of FIG. 41A.

FIG. 42 illustrates an example translation process for generating anoutput message based on an input message and a comparison withtranslation rules associated with the translation module.

FIG. 43A illustrates an example translation process in which thetranslation module facilitates communication of an HL7 message from aHospital Information System (“HIS”) having a first HL7 format to anintended recipient medical device having a second HL7 format.

FIG. 43B illustrates an example translation process in which thetranslation module facilitates communication of an HL7 message from amedical device having a first HL7 format to a HIS having a second HL7format.

FIG. 44 illustrates an example screenshot from a messagingimplementation tool for manually configuring translation rules to beused by the translation module.

FIGS. 45A and 45B illustrate example automatic rule configurationprocesses that can be performed by the translation module.

FIGS. 45C and 45D illustrate example automatic rule configurationprocesses that can be performed by the translation module for messagesutilizing the HL7 protocol.

While the foregoing “Brief Description of the Drawings” referencesgenerally various embodiments of the disclosure, an artisan willrecognize from the disclosure herein that such embodiments are notmutually exclusive. Rather, the artisan would recognize a myriad ofcombinations of some or all of such embodiments.

DETAILED DESCRIPTION I. Introduction

Based on at least the foregoing, a solution is needed that coordinatesthe various medical devices treating or monitoring a patient.Embodiments of such a solution should provide patient identificationseamlessly across the device space and embodiments of such a solutionshould expand for future technologies without necessarily requiringrepeated software upgrades. In addition, embodiments of such a solutionmay include patient electrical isolation where desired.

Therefore, the present disclosure relates to a patient monitoring hubthat is the center of patient monitoring and treatment activities for agiven patient. Embodiments of the patient monitoring hub interface withlegacy devices without necessitating legacy reprogramming, provideflexibility for interfacing with future devices without necessitatingsoftware upgrades, and offer optional patient electrical isolation. Inan embodiment, the hub includes a large display dynamically providinginformation to a caregiver about a wide variety of measurement orotherwise determined parameters. Additionally, in an embodiment, the hubincludes a docking station for a portable patient monitor. The portablepatient monitor may communicate with the hub through the docking stationor through various wireless paradigms known to an artisan from thedisclosure herein, including WiFi, Bluetooth, Zigbee, or the like.

In still other embodiments, the portable patient monitor modifies itsscreen when docked. The undocked display indicia is in part or in wholetransferred to a large dynamic display of the hub and the docked displaypresents one or more anatomical graphics of monitored body parts. Forexample, the display may present a heart, lungs, a brain, kidneys,intestines, a stomach, other organs, digits, gastrointestinal systems orother body parts when it is docked. In an embodiment, the anatomicalgraphics may advantageously be animated. In an embodiment, the animationmay generally follow the behavior of measured parameters, such as, forexample, the lungs may inflate in approximate correlation to themeasured respiration rate and/or the determined inspiration portion of arespiration cycle, and likewise deflate according to the expirationportion of the same. The heart may beat according to the pulse rate, maybeat generally along understood actual heart contraction patterns, andthe like. Moreover, in an embodiment, when the measured parametersindicate a need to alert a caregiver, a changing severity in color maybe associated with one or more displayed graphics, such as the heart,lungs, brain, or the like. In still other embodiments, the body portionsmay include animations on where, when or how to attach measurementdevices to measurement sites on the patient. For example, the monitormay provide animated directions for CCHD screening procedures or glucosestrip reading protocols, the application of a forehead sensor, a fingeror toe sensor, one or more electrodes, an acoustic sensor, and earsensor, a cannula sensor or the like.

The present disclosure relates to a medical monitoring hub configured tobe the center of monitoring activity for a given patient. In anembodiment, the hub comprises a large easily readable display, such asan about ten (10) inch display dominating the majority of real estate ona front face of the hub. The display could be much larger or muchsmaller depending upon design constraints. However, for portability andcurrent design goals, the preferred display is roughly sizedproportional to the vertical footprint of one of the dockable portablepatient monitors. Other considerations are recognizable from thedisclosure herein by those in the art.

The display provides measurement data for a wide variety of monitoredparameters for the patient under observation in numerical or graphicform, and in various embodiments, is automatically configured based onthe type of data and information being received at the hub. In anembodiment, the hub is moveable, portable, and mountable so that it canbe positioned to convenient areas within a caregiver environment. Forexample, the hub is collected within a singular housing.

In an embodiment, the hub may advantageously receive data from aportable patient monitor while docked or undocked from the hub. Typicalportable patient monitors, such as oximeters or co-oximeters can providemeasurement data for a large number of physiological parameters derivedfrom signals output from optical and/or acoustic sensors, electrodes, orthe like. The physiological parameters include, but not limited tooxygen saturation, carboxy hemoglobin, methemoglobin, total hemoglobin,glucose, pH, bilirubin, fractional saturation, pulse rate, respirationrate, components of a respiration cycle, indications of perfusionincluding perfusion index, signal quality and/or confidences,plethysmograph data, indications of wellness or wellness indexes orother combinations of measurement data, audio information responsive torespiration, ailment identification or diagnosis, blood pressure,patient and/or measurement site temperature, depth of sedation, organ orbrain oxygenation, hydration, measurements responsive to metabolism,combinations of the same or the like, to name a few. In otherembodiments, the hub may output data sufficient to accomplishclosed-loop drug administration in combination with infusion pumps orthe like.

In an embodiment, the hub communicates with other devices in amonitoring environment that are interacting with the patient in a numberof ways. For example, the hub advantageously receives serial data fromother devices without necessitating their reprogramming or that of thehub. Such other devices include pumps, ventilators, all manner ofmonitors monitoring any combination of the foregoing parameters,ECG/EEG/EKG devices, electronic patient beds, and the like. Moreover,the hub advantageously receives channel data from other medical deviceswithout necessitating their reprogramming or that of the hub. When adevice communicates through channel data, the hub may advantageouslyalter the large display to include measurement information from thatdevice. Additionally, the hub accesses nurse call systems to ensure thatnurse call situations from the device are passed to the appropriatenurse call system.

The hub also communicates with hospital systems to advantageouslyassociate incoming patient measurement and treatment data with thepatient being monitored. For example, the hub may communicate wirelesslyor otherwise to a multi-patient monitoring system, such as a server orcollection of servers, which in turn many communicate with a caregiver'sdata management systems, such as, for example, an Admit, Discharge,Transfer (“ADT”) system and/or an Electronic Medical Records (“EMR”)system. The hub advantageously associates the data flowing through itwith the patient being monitored thereby providing the electronicmeasurement and treatment information to be passed to the caregiver'sdata management systems without the caregiver associating each device inthe environment with the patient.

In an embodiment, the hub advantageously includes a reconfigurable andremovable docking station. The docking station may dock additionallayered docking stations to adapt to different patient monitoringdevices. Additionally, the docking station itself is modularized so thatit may be removed if the primary dockable portable patient monitorchanges its form factor. Thus, the hub is flexible in how its dockingstation is configured.

In an embodiment, the hub includes a large memory for storing some orall of the data it receives, processes, and/or associates with thepatient, and/or communications it has with other devices and systems.Some or all of the memory may advantageously comprise removable SDmemory.

The hub communicates with other devices through at least (1) the dockingstation to acquire data from a portable monitor, (2) innovativeuniversal medical connectors to acquire channel data, (3) serial dataconnectors, such as RJ ports to acquire output data, (4) Ethernet, USB,and nurse call ports, (5) Wireless devices to acquire data from aportable monitor, (6) other wired or wireless communication mechanismsknown to an artisan. The universal medical connectors advantageouslyprovide optional electrically isolated power and communications, aredesigned to be smaller in cross section than isolation requirements. Theconnectors and the hub communicate to advantageously translate orconfigure data from other devices to be usable and displayable for thehub. In an embodiment, a software developers kit (“SDK”) is provided toa device manufacturer to establish or define the behavior and meaning ofthe data output from their device. When the output is defined, thedefinition is programmed into a memory residing in the cable side of theuniversal medical connector and supplied as an original equipmentmanufacture (“OEM”) to the device provider. When the cable is connectedbetween the device and the hub, the hub understands the data and can useit for display and processing purposes without necessitating softwareupgrades to the device or the hub. In an embodiment, the hub cannegotiate the schema and even add additional compression and/orencryption. Through the use of the universal medical connectors, the huborganizes the measurement and treatment data into a single display andalarm system effectively and efficiently bringing order to themonitoring environment.

As the hub receives and tracks data from other devices according to achannel paradigm, the hub may advantageously provide processing tocreate virtual channels of patient measurement or treatment data. In anembodiment, a virtual channel may comprise a non-measured parameter thatis, for example, the result of processing data from various measured orother parameters. An example of such a parameter includes a wellnessindicator derived from various measured parameters that give an overallindication of the wellbeing of the monitored patient. An example of awellness parameter is disclosed in U.S. patent application Ser. Nos.13/269,296, 13/371,767 and 12/904,925, by the assignee of the presentdisclosure and incorporated by reference herein. By organizing data intochannels and virtual channels, the hub may advantageously time-wisesynchronize incoming data and virtual channel data.

The hub also receives serial data through serial communication ports,such as RJ connectors. The serial data is associated with the monitoredpatient and passed on to the multi-patient server systems and/orcaregiver backend systems discussed above. Through receiving the serialdata, the caregiver advantageously associates devices in the caregiverenvironment, often from varied manufactures, with a particular patient,avoiding a need to have each individual device associated with thepatient and possible communicating with hospital systems. Suchassociation is vital as it reduces caregiver time spent enteringbiographic and demographic information into each device about thepatient. Moreover, in an embodiment, through the SDK the devicemanufacturer may advantageously provide information associated with anymeasurement delay of their device, thereby further allowing the hub toadvantageously time-wise synchronize serial incoming data and other dataassociated with the patient.

In an embodiment, when a portable patient monitor is docked, and itincludes its own display, the hub effectively increases its display realestate. For example, in an embodiment, the portable patient monitor maysimply continue to display its measurement and/or treatment data, whichmay be now duplicated on the hub display, or the docked display mayalter its display to provide additional information. In an embodiment,the docked display, when docked, presents anatomical graphical data of,for example, the heart, lungs, organs, the brain, or other body partsbeing measured and/or treated. The graphical data may advantageouslyanimate similar to and in concert with the measurement data. Forexample, lungs may inflate in approximate correlation to the measuredrespiration rate and/or the determined inspiration/expiration portionsof a respiration cycle, the heart may beat according to the pulse rate,may beat generally along understood actual heart contraction patterns,the brain may change color or activity based on varying depths ofsedation, or the like. In an embodiment, when the measured parametersindicate a need to alert a caregiver, a changing severity in color maybe associated with one or more displayed graphics, such as the heart,lungs, brain, organs, circulatory system or portions thereof,respiratory system or portions thereof, other body parts or the like. Instill other embodiments, the body portions may include animations onwhere, when or how to attach measurement devices.

The hub may also advantageously overlap parameter displays to provideadditional visual information to the caregiver. Such overlapping may beuser definable and configurable. The display may also incorporateanalog-appearing icons or graphical indicia.

In the interest of clarity, not all features of an actual implementationare described in this specification. An artisan will of course beappreciate that in the development of any such actual implementation (asin any development project), numerous implementation-specific decisionsmust be made to achieve a developers' specific goals and subgoals, suchas compliance with system- and business-related constraints, which willvary from one implementation to another. Moreover, it will beappreciated that such a development effort might be complex andtime-consuming, but would nevertheless be a routine undertaking ofdevice engineering for those of ordinary skill having the benefit ofthis disclosure.

To facilitate a complete understanding of the disclosure, the remainderof the detailed description describes the disclosure with reference tothe drawings, wherein like reference numbers are referenced with likenumerals throughout.

II. Example Hub Embodiments

FIG. 1A illustrates a monitoring environment including a perspectiveview of an exemplary medical monitoring hub 100 with an exemplary dockedportable patient monitor 102 according to an embodiment of thedisclosure. The hub 100 includes a display 104, and a docking station106, which in an embodiment is configured to mechanically andelectrically mate with the portable patient monitor 102, each housed ina movable, mountable and portable housing 108. The housing 108 includesa generally upright inclined shape configured to rest on a horizontalflat surface, although the housing 108 can be affixed in a wide varietyof positions and mountings and comprise a wide variety of shapes andsizes.

In an embodiment, the display 104 may present a wide variety ofmeasurement and/or treatment data in numerical, graphical, waveform, orother display indicia 110. In an embodiment, the display 104 occupiesmuch of a front face of the housing 108, although an artisan willappreciate the display 104 may comprise a tablet or tabletop horizontalconfiguration, a laptop-like configuration or the like. Otherembodiments may include communicating display information and data to atable computer, smartphone, television, or any display systemrecognizable to an artisan. The upright inclined configuration of FIG.1A presents display information to a caregiver in an easily viewablemanner.

FIG. 1B shows a perspective side view of an embodiment of the hub 100including the housing 108, the display 104, and the docking station 106without a portable monitor docked. Also shown is a connector fornoninvasive blood pressure.

In an embodiment, the housing 108 may also include pockets orindentations to hold additional medical devices, such as, for example, ablood pressure monitor or temperature sensor 112, such as that shown inFIG. 1C.

The portable patient monitor 102 of FIG. 1A may advantageously comprisean oximeter, co-oximeter, respiratory monitor, depth of sedationmonitor, noninvasive blood pressure monitor, vital signs monitor or thelike, such as those commercially available from Masimo Corporation ofIrvine, Calif., and/or disclosed in U.S. Pat. Pub. Nos. 2002/0140675,2010/0274099, 2011/0213273, 2012/0226117, 2010/0030040; U.S. Pat. App.Ser. Nos. 61/242,792, 61/387,457, 61/645,570, 13/554,908 and U.S. Pat.Nos. 6,157,850, 6,334,065, and the like. The monitor 102 may communicatewith a variety of noninvasive and/or minimally invasive devices such asoptical sensors with light emission and detection circuitry, acousticsensors, devices that measure blood parameters from a finger prick,cuffs, ventilators, and the like. The monitor 102 may include its owndisplay 114 presenting its own display indicia 116, discussed below withreference to FIGS. 19A-19J. The display indicia may advantageouslychange based on a docking state of the monitor 102. When undocked, thedisplay indicia may include parameter information and may alterorientation based on, for example, a gravity sensor or accelerometer.

In an embodiment, the docking station 106 of the hub 100 includes amechanical latch 118, or mechanically releasable catch to ensure thatmovement of the hub 100 doesn't mechanically detach the monitor 102 in amanner that could damage the same.

Although disclosed with reference to particular portable patientmonitors 102, an artisan will recognize from the disclosure herein alarge number and wide variety of medical devices that may advantageouslydock with the hub 100. Moreover, the docking station 106 mayadvantageously electrically and not mechanically connect with themonitor 102, and/or wirelessly communicate with the same.

FIG. 2 illustrates a simplified block diagram of an exemplary monitoringenvironment 200 including the hub 100 of FIG. 1, according to anembodiment of the disclosure. As shown in FIG. 2, the environment mayinclude the portable patient monitor 102 communicating with one or morepatient sensors 202, such as, for example, oximetry optical sensors,acoustic sensors, blood pressure sensors, respiration sensors or thelike. In an embodiment, additional sensors, such as, for example, a NIBPsensor or system 211 and a temperature sensor or sensor system 213 maycommunicate directly with the hub 100. The sensors 202, 211 and 213 whenin use are typically in proximity to the patient being monitored if notactually attached to the patient at a measurement site.

As disclosed, the portable patient monitor 102 communicates with the hub100, in an embodiment, through the docking station 106 when docked and,in an embodiment, wirelessly when undocked, however, such undockedcommunication is not required. The hub 100 communicates with one or moremulti-patient monitoring servers 204 or server systems, such as, forexample, those disclosed with in U.S. Pat. Pub. Nos. 2011/0105854,2011/0169644, and 2007/0180140. In general, the server 204 communicateswith caregiver backend systems 206 such as EMR and/or ADT systems. Theserver 204 may advantageously obtain through push, pull or combinationtechnologies patient information entered at patient admission, such asdemographical information, billing information, and the like. The hub100 accesses this information to seamlessly associate the monitoredpatient with the caregiver backend systems 206. Communication betweenthe server 204 and the monitoring hub 100 may be any recognizable to anartisan from the disclosure herein, including wireless, wired, overmobile or other computing networks, or the like.

FIG. 2 also shows the hub 100 communicating through its serial dataports 210 and channel data ports 212. As disclosed in the forgoing, theserial data ports 210 may provide data from a wide variety of patientmedical devices, including electronic patient bed systems 214, infusionpump systems 216 including closed loop control systems, ventilatorsystems 218, blood pressure or other vital sign measurement systems 220,or the like. Similarly, the channel data ports 212 may provide data froma wide variety of patient medical devices, including any of theforegoing, and other medical devices. For example, the channel dataports 212 may receive data from depth of consciousness monitors 222,such as those commercially available from SEDLine, brain or other organoximeter devices 224, noninvasive blood pressure or acoustic devices226, or the like. In an embodiment, channel device may includeboard-in-cable (“BIC”) solutions where the processing algorithms and thesignal processing devices that accomplish those algorithms are mountedto a board housed in a cable or cable connector, which in someembodiments has no additional display technologies. The BIC solutionoutputs its measured parameter data to the channel port 212 to bedisplayed on the display 104 of hub 100. In an embodiment, the hub 100may advantageously be entirely or partially formed as a BIC solutionthat communicates with other systems, such as, for example, tablets,smartphones, or other computing systems.

Although disclosed with reference to a single docking station 106, theenvironment 200 may include stacked docking stations where a subsequentdocking station mechanically and electrically docks to a first dockingstation to change the form factor for a different portable patentmonitor as discussed with reference to FIG. 5. Such stacking may includemore than 2 docking stations, may reduce or increase the form fact formechanical compliance with mating mechanical structures on a portabledevice.

FIG. 3 illustrates a simplified exemplary hardware block diagram of thehub 100 of FIG. 1, according to an embodiment of the disclosure. Asshown in FIG. 3, the housing 108 of the hub 100 positions and/orencompasses an instrument board 302, the display 104, memory 304, andthe various communication connections, including the serial ports 210,the channel ports 212, Ethernet ports 305, nurse call port 306, othercommunication ports 308 including standard USB or the like, and thedocking station interface 310. The instrument board 302 comprises one ormore substrates including communication interconnects, wiring, ports andthe like to enable the communications and functions described herein,including inter-board communications. A core board 312 includes the mainparameter, signal, and other processor(s) and memory, a portable monitorboard (“RIB”) 314 includes patient electrical isolation for the monitor102 and one or more processors, a channel board (“MID”) 316 controls thecommunication with the channel ports 212 including optional patientelectrical isolation and power supply 318, and a radio board 320includes components configured for wireless communications.Additionally, the instrument board 302 may advantageously include one ormore processors and controllers, busses, all manner of communicationconnectivity and electronics, memory, memory readers including EPROMreaders, and other electronics recognizable to an artisan from thedisclosure herein. Each board comprises substrates for positioning andsupport, interconnect for communications, electronic componentsincluding controllers, logic devices, hardware/software combinations andthe like to accomplish the tasks designated above and others.

An artisan will recognize from the disclosure herein that the instrumentboard 302 may comprise a large number of electronic components organizedin a large number of ways. Using different boards such as thosedisclosed above advantageously provides organization andcompartmentalization to the complex system.

FIG. 4 illustrates a perspective view of an exemplary removable dockingstation 400 of the hub 100 of FIG. 1, according to an embodiment of thedisclosure. As shown in FIG. 4, the docking station 400 provides amechanical mating to portable patient monitor 102 to provide securemechanical support when the monitor 102 is docked. The docking station400 includes a cavity 402 shaped similar to the periphery of a housingof the portable monitor 102. The station 400 also includes one or moreelectrical connectors 404 providing communication to the hub 100.Although shown as mounted with bolts, the docking station 400 may snapfit, may use movable tabs or catches, may magnetically attach, or mayemploy a wide variety or combination of attachment mechanisms know to anartisan from the disclosure herein. In an embodiment, the attachment ofthe docking station 400 should be sufficiently secure that when docked,the monitor 102 and docking station cannot be accidentally detached in amanner that could damage the instruments, such as, for example, if thehub 100 was accidently bumped or the like, the monitor 102 and dockingstation 400 should remain intact.

The housing 108 of the hub 100 also includes cavity 406 housing thedocking station 400. To the extent a change to the form factor for theportable patient monitor 102 occurs, the docking station 400 isadvantageously removable and replaceable. Similar to the docking station400, the hub 100 includes within the cavity 406 of the housing 108electrical connectors 408 providing electrical communication to thedocking station 400. In an embodiment, the docking station 400 includesits own microcontroller and processing capabilities, such as thosedisclosed in U.S. Pat. Pub. No. 2002/0140675. In other embodiments, thedocking station 400 passes communications through to the electricalconnector 408.

FIG. 4 also shows the housing 108 including openings for channel ports212 as universal medical connectors discussed in detail below.

FIG. 5 illustrates a perspective view of exemplary portable patientmonitors 502 and 504 undocked from the hub 100 of FIG. 1, according toan embodiment of the disclosure. As shown in FIG. 5, the monitor 502 maybe removed and other monitors, like monitor 504 may be provided. Thedocking station 106 includes an additional docking station 506 thatmechanically mates with the original docking station 106 and presents aform factor mechanically matable with monitor 504. In an embodiment, themonitor 504 mechanically and electrically mates with the stacked dockingstations 506 and 106 of hub 100. As can be readily appreciated by andartisan from the disclosure herein, the stackable function of thedocking stations provides the hub 100 with an extremely flexiblemechanism for charging, communicating, and interfacing with a widevariety of patient monitoring devices. As noted above, the dockingstations may be stacked, or in other embodiments, removed and replaced.

FIG. 6 illustrates a simplified block diagram of traditional patientelectrical isolation principles. As shown in FIG. 6, a host device 602is generally associated with a patient device 604 through communicationand power. As the patient device 604 often comprises electronicsproximate or connected to a patient, such as sensors or the like,certain safety requirements dictate that electrical surges of energyfrom, for example, the power grid connected to the host device, shouldnot find an electrical path to the patient. This is generally referredto a “patient isolation” which is a term known in the art and includesherein the removing of direct uninterrupted electrical paths between thehost device 602 and the patient device 604. Such isolation isaccomplished through, for example, isolation devices 606 on powerconductors 608 and communication conductors 610. Isolation devices 606can include transformers, optical devices that emit and detect opticalenergy, and the like. Use of isolation devices, especially on powerconductors, can be expensive component wise, expensive size wise, anddrain power. Traditionally, the isolation devices were incorporated intothe patient device 604, however, the patient devices 604 are trendingsmaller and smaller and not all devices incorporate isolation.

FIG. 7A illustrates a simplified block diagram of an exemplary optionalpatient isolation system according to an embodiment of the disclosure.As shown in FIG. 7A, the host device 602 communicates with an isolatedpatient device 604 through isolation devices 606. However, a memory 702associated with a particular patient device informs the host 602 whetherthat device needs isolated power. If a patient device 708 does not needisolated power, such as some types of cuffs, infusion pumps,ventilators, or the like, then the host 602 can provide non-isolatedpower through signal path 710. This power may be much higher that whatcan cost-effectively be provided through the isolated power conductor608. In an embodiment, the non-isolated patient devices 708 receiveisolated communication as such communication is typically at lowervoltages and is not cost prohibitive. An artisan will recognize from thedisclosure herein that communication could also be non-isolated. Thus,FIG. 7A shows a patient isolation system 700 that provides optionalpatient isolation between a host 602 and a wide variety of potentialpatient devices 604, 708. In an embodiment, the hub 100 includes thechannel ports 212 incorporating similar optional patient isolationprinciples.

FIG. 7B adds an exemplary optional non-isolation power levels for thesystem of FIG. 7A according to an embodiment of the disclosure. As shownin FIG. 7B, once the host 602 understands that the patient device 604comprises a self-isolated patient device 708, and thus does not needisolated power, the host 602 provides power through a separate conductor710. Because the power is not isolated, the memory 702 may also providepower requirements to the host 602, which may select from two or morevoltage or power levels. In FIG. 7B, the host 602 provides either highpower, such as about 12 volts, but could have a wide range of voltagesor very high power such as about 24 volts or more, but could have a widerange of voltages, to the patient device 708. An artisan will recognizethat supply voltages can advantageously be altered to meet the specificneeds of virtually any device 708 and/or the memory could supplyinformation to the host 602 which provided a wide range of non-isolatedpower to the patient device 708.

Moreover, using the memory 702, the host 602 may determine to simply notenable any unused power supplies, whether that be the isolated power orone or more of the higher voltage non-isolated power supplies, therebyincreasing the efficiency of the host.

FIG. 8 illustrates a simplified exemplary universal medical connectorconfiguration process 800, according to an embodiment of the disclosure.As shown in FIG. 8, the process includes step 802, where a cable isattached to a universal medical connector incorporating optional patientisolation as disclosed in the foregoing. In step 804, the host device602 or the hub 100, more specifically, the channel data board 316 orEPROM reader of the instrument board, reads the data stored in thememory 702 and in step 806, determines whether the connecting devicerequires isolated power. In step 808, when the isolated power isrequired, the hub 100 may advantageously enable isolated power and instep 810, enable isolated communications. In step 806, when isolatedpower is not needed, the hub 100 may simply in optional step 812 enablenon-isolated power and in embodiments where communications remainisolated, step 810 enable isolated communications. In other optionalembodiments, in step 806, when isolated power is not needed, the hub 100in step 814 may use information from memory 702 to determine the amountof power needed for the patient device 708. When sufficient power is notavailable, because for example, other connected devices are also usingconnected power, in step 816 a message may be displayed indicating thesame and power is not provided. When sufficient power is available,optional step 812 may enable non-isolated power. Alternatively, optionalstep 818 may determine whether memory 702 indicates higher or lowerpower is desired. When higher power is desired, the hub 100 may enablehigher power in step 820 and when not, may enable lower power in step822. The hub 100 in step 810 then enables isolated communication. In anembodiment, the hub 100 in step 818 may simply determine how much poweris needed and provide at least sufficient power to the self-isolateddevice 708.

An artisan will recognize from the disclosure herein that hub 100 maynot check to see if sufficient power is available or may provide one,two or many levels of non-isolated voltages based on information fromthe memory 702.

FIGS. 9A and 9B illustrate simplified block diagrams of exemplaryuniversal medical connectors 900 having a size and shape smaller incross section than tradition isolation requirements. In an embodiment,the connector 900 physically separates non-isolated signals on one side910 from isolated signals on another side 920, although the sides couldbe reversed. The gap between such separations may be dictated at leastin part by safety regulations governing patient isolation. In anembodiment, the distance between the sides 910 and 920 may appear to betoo small.

As shown from a different perspective in FIG. 9B, the distance betweenconnectors “x” appears small. However, the gap causes the distance toincludes a non-direct path between conductors. For example, any shortwould have to travel path 904, and the distance of such path is withinor beyond such safety regulations, in that the distance is greater than“x.” It is noteworthy that the non-straight line path 904 occursthroughout the connector, such as, for example, on the board connectorside where solder connects various pins to a PCB board.

FIG. 10 illustrates a perspective view of a side of the hub 100 of FIG.1, showing exemplary instrument-side channel inputs 1000 as exemplaryuniversal medical connectors. As shown in FIG. 10, the inputs includethe non-isolated side 910, the isolated side 920, and the gap. In anembodiment, the memory 710 communicates through pins on the non-isolatedside.

FIGS. 11A-11K illustrate various views of exemplary male and matingfemale universal medical connectors, according to embodiments of thedisclosure. For example, FIGS. 11G1 and 11G2 shows various preferred butnot required sizing, and FIG. 11H shows incorporation of electroniccomponents, such as the memory 702 into the connectors. FIGS. 11I-11Killustrate wiring diagrams and cabling specifics of the cable itself asit connects to the universal medical connectors.

FIG. 12 illustrates a simplified block diagram of a channel system forthe hub of FIG. 1, according to an embodiment of the disclosure. Asshown in FIG. 12, a male cable connector, such as those shown in FIG. 11above, includes a memory such as an EPROM. The memory advantageouslystores information describing the type of data the hub 100 can expect toreceive, and how to receive the same. A controller of the hub 100communicates with the EPROM to negotiate how to receive the data, and ifpossible, how to display the data on display 104, alarm when needed, andthe like. For example, a medical device supplier may contact the hubprovider and receive a software developers' kit (“SDK”) that guides thesupplier through how to describe the type of data output from theirdevice. After working with the SDK, a map, image, or other translationfile may advantageously be loaded into the EPROM, as well as the powerrequirements and isolation requirements discussed above. When thechannel cable is connected to the hub 100 through the channel port 212,the hub 100 reads the EPROM and the controller of the hub 100 negotiateshow to handle incoming data.

FIG. 13 illustrates an exemplary logical channel configuration that maybe stored in the EPROM of FIG. 12. As shown in FIG. 13, each incomingchannel describes one or more parameters. Each parameter describeswhatever the hub 100 should know about the incoming data. For example,the hub 100 may want to know whether the data is streaming data,waveform data, already determined parameter measurement data, ranges onthe data, speed of data delivery, units of the data, steps of the units,colors for display, alarm parameters and thresholds, including complexalgorithms for alarm computations, other events that are parameter valuedriven, combinations of the same or the like. Additionally, theparameter information may include device delay times to assist in datasynchronization or approximations of data synchronization acrossparameters or other data received by the hub 100. In an embodiment, theSDK presents a schema to the device supplier which self-describes thetype and order of incoming data. In an embodiment, the informationadvantageously negotiates with the hub 100 to determine whether to applycompression and/or encryption to the incoming data stream.

Such open architecture advantageously provides device manufacturers theability to port the output of their device into the hub 100 for display,processing, and data management as disclosed in the foregoing. Byimplementation through the cable connector, the device manufactureravoids any reprogramming of their original device; rather, they simplylet the hub 100 know through the cable connector how the alreadyexisting output is formatted. Moreover, by describing the data in alanguage already understood by the hub 100, the hub 100 also avoidssoftware upgrades to accommodate data from “new-to-the-hub” medicaldevices.

FIG. 14 illustrates a simplified exemplary process for configuring achannel according to an embodiment of the disclosure. As shown in FIG.14, the hub provider provides a device manufacturer with an SDK in step1402, who in turn uses the SDK to self-describe the output data channelfrom their device in step 1404. In an embodiment, the SDK is a series ofquestions that guide the development, in other embodiments, the SDKprovides a language and schema to describe the behavior of the data.

Once the device provider describes the data, the hub provider creates abinary image or other file to store in a memory within a cable connectorin step 1405; however, the SDK may create the image and simplycommunicated it to the hub provider. The cable connector is provided asan OEM part to the provider in step 1410, who constructs andmanufactures the cable to mechanically and electrically mate with outputports on their devices in step 1412.

Once a caregiver has the appropriately manufactured cable, with one endmatching the device provider's system and the other OEM'ed to match thehub 100 at its channel ports 212, in step 1452 the caregiver can connectthe hub between the devices. In step 1454, the hub 100 reads the memory,provides isolated or non-isolated power, and the cable controller andthe hub 100 negotiate a protocol or schema for data delivery. In anembodiment, a controller on the cable may negotiated the protocol, in analternative embodiment, the controller of the hub 100 negotiates withother processors on the hub the particular protocol. Once the protocolis set, the hub 100 can use, display and otherwise process the incomingdata stream in an intelligent manner.

Through the use of the universal medical connectors described herein,connection of a myriad of devices to the hub 100 is accomplished throughstraightforward programming of a cable connector as opposed tonecessitating software upgrades to each device.

FIG. 15 illustrates a perspective view of the hub of FIG. 1 including anexemplary attached board-in-cable (“BIC”) to form an input channelaccording to an embodiment of the disclosure. As shown in FIG. 15, aSEDLine depth of consciousness board communicates data from anappropriate patient sensor to the hub 100 for display and caregiverreview. As described, the provider of the board need only use the SDK todescribe their data channel, and the hub 100 understands how to presentthe data to the caregiver.

FIG. 16 illustrates a perspective view of a back side of the hub 100 ofFIG. 1, showing an exemplary serial data inputs. In an embodiment, theinputs include such as RJ 45 ports. As is understood in the art, theseports include a data ports similar to those found on computers, networkrouters, switches and hubs. In an embodiment, a plurality of these portsare used to associate data from various devices with the specificpatient identified in the hub 100. FIG. 16 also shows a speaker, thenurse call connector, the Ethernet connector, the USBs, a powerconnector and a medical grounding lug.

FIG. 17A illustrates an exemplary monitoring environment withcommunication through the serial data connections of the hub 100 of FIG.1, according to an embodiment of the disclosure. As shown and asdiscussed in the foregoing, the hub 100 may use the serial data ports210 to gather data from various devices within the monitoringenvironment, including an electronic bed, infusion pumps, ventilators,vital sign monitors, and the like. The difference between the datareceived from these devices and that received through the channel ports212 is that the hub 100 may not know the format or structure of thisdata. The hub 100 may not display information from this data or use thisdata in calculations or processing. However, porting the data throughthe hub 100 conveniently associates the data with the specificallymonitored patient in the entire chain of caregiver systems, includingthe foregoing server 214 and backend systems 206. In an embodiment, thehub 100 may determine sufficient information about the incoming data toattempt to synchronize it with data from the hub 100.

In FIG. 17B, a control screen may provide information on the type ofdata being received. In an embodiment, a green light next to the dataindicates connection to a device and on which serial input theconnection occurs.

FIG. 18 illustrates a simplified exemplary patient data flow process,according to an embodiment of the disclosure. As shown, once a patientis admitted into the caregiver environment at step 1802, data about thepatient is populated on the caregiver backend systems 206. The server214 may advantageously acquire or receive this information in step 1804,and then make it accessible to the hub 100. When the caregiver at step1806 assigns the hub 100 to the patient, the caregiver simply looks atthe presently available patient data and selects the particular patientbeing currently monitored. The hub 100 at step 1808 then associates themeasurement, monitoring and treatment data it receives and determineswith that patient. The caregiver need not again associate another devicewith the patient so long as that device is communicating through the hub100 by way of (1) the docking station, (2) the universal medicalconnectors, (3) the serial data connectors, or (4) other communicationmechanisms known to an artisan. At step 1810, some or the entirety ofthe received, processed and/or determined data is passed to the serversystems discussed above.

FIGS. 19A-19J illustrate exemplary displays of anatomical graphics forthe portable patient monitor docked with the hub 100 of FIG. 1,according to embodiments of the disclosure. As shown in FIG. 19A, theheart, lungs and respiratory system are shown while the brain is nothighlighted. Thus, a caregiver can readily determine that depth ofconsciousness monitoring or brain oximetry systems are not currentlycommunicating with the hub 100 through the portable patient monitorconnection or the channel data ports. However, it is likely thatacoustic or other respiratory data and cardiac data is beingcommunicated to or measured by the hub 100. Moreover, the caregiver canreadily determine that the hub 100 is not receiving alarming data withrespect to the emphasized body portions. In an embodiment, theemphasized portion may animate to show currently measured behavior or,alternatively, animate in a predetermined fashion.

FIG. 19B shows the addition of a virtual channel showing an indicationof wellness. As shown in FIG. 19B, the indication is positive as it is a“34” on an increasingly severity scale to “100.” The wellness indicationmay also be shaded to show problems. In contrast to FIG. 19B, FIG. 19Cshows a wellness number that is becoming or has become problematic andan alarming heart graphic. Thus, a caregiver responding to a patientalarm on the hub 100 or otherwise on another device or system monitoringor treating the patient can quickly determine that a review of vitalsigns and other parameters relating to heart function is needed todiagnose and/or treat the patient.

FIGS. 19D and 19E show the brain included in the emphasized bodyportions meaning that the hub 100 is receiving data relevant to brainfunctions, such as, for example, depth of sedation data or brainoximetry data. FIG. 19E additionally shows an alarming heart functionsimilar to FIG. 19C.

In FIG. 19F, additional organs, such as the kidneys are being monitored,but the respiratory system is not. In FIG. 19G, an alarming hearfunction is shown, and in FIG. 19H, an alarming circulatory system isbeing shown. FIG. 19I shows the wellness indication along with lungs,heart, brain and kidneys. FIG. 19J shows alarming lungs, heart, andcirculatory system as well as the wellness indication. Moreover, FIG.19J shows a severity contrast, such as, for example, the heart alarmingred for urgent while the circulatory system alarms yellow for caution.An artisan will recognize other color schemes that are appropriate fromthe disclosure herein.

FIGS. 20A-20C illustrate exemplary displays of measurement data showingdata separation and data overlap, respectively, according embodiments ofthe disclosure. FIGS. 21A and 21B illustrate exemplary displays ofmeasurement data also showing data separation and data overlap,respectively, according embodiments of the disclosure.

For example, acoustic data from an acoustic sensor may advantageouslyprovide breath sound data, while the plethysmograph and ECG or othersignals can also be presented in separate waveforms (FIG. 20A, top ofthe screen capture). The monitor may determine any of a variety ofrespiratory parameters of a patient, including respiratory rate,expiratory flow, tidal volume, minute volume, apnea duration, breathsounds, riles, rhonchi, stridor, and changes in breath sounds such asdecreased volume or change in airflow. In addition, in some cases asystem monitors other physiological sounds, such as heart rate to helpwith probe off detection, heart sounds (S1, S2, S3, S4, and murmurs),and change in heart sounds such as normal to murmur or split heartsounds indicating fluid overload.

Providing a visual correlation between multiple physiological signalscan provide a number of valuable benefits where the signals have someobservable physiological correlation. As one example of such acorrelation, changes in morphology (e.g., envelope and/or baseline) ofthe plethysmographic signal can be indicative of patient blood or otherfluid levels. And, these changes can be monitored to detect hypovolemiaor other fluid-level related conditions. A pleth variability index mayprovide an indication of fluid levels, for example. And, changes in themorphology of the plethysmographic signal are correlated to respiration.For example, changes in the envelope and/or baseline of theplethysmographic signal are correlated to breathing. This is at least inpart due to aspects of the human anatomical structure, such as themechanical relationship and interaction between the heart and the lungsduring respiration.

Thus, superimposing a plethysmographic signal and a respiratory signal(FIG. 20B) can give operators an indication of the validity of theplethysmographic signal or signals derived therefrom, such as a plethvariability index. For example, if bursts in the respiration signalindicative of inhalation and exhalation correlate with changes in peaksand valleys of the plethysmographic envelope, this gives monitoringpersonnel a visual indication that the plethysmographic changes areindeed due to respiration, and not some other extraneous factor.Similarly, if the bursts in the respiration signal line up with thepeaks and valleys in the plethysmographic envelope, this providesmonitoring personnel an indication that the bursts in the respirationsignal are due to patient breathing sounds, and not some othernon-targeted sounds (e.g., patient non-breathing sounds or non-patientsounds).

The monitor may also be configured to process the signals and determinewhether there is a threshold level of correlation between the twosignals, or otherwise assess the correlation. However, by additionallyproviding a visual indication of the correlation, such as by showing thesignals superimposed with one another, the display provides operators acontinuous, intuitive and readily observable gauge of the particularphysiological correlation. For example, by viewing the superimposedsignals, users can observe trends in the correlation over time, whichmay not be otherwise ascertainable.

The monitor can visually correlate a variety of other types of signalsinstead of, or in addition to plethysmographic and respiratory signals.For example, FIG. 20C depicts a screen shot of another examplemonitoring display. As shown in the upper right portion of FIG. 20C, thedisplay superimposes a plethysmographic signal, an ECG signal, and arespiration signal. In other configurations, more than three differenttypes of signals may be overlaid onto one another.

In one embodiment, the hub 100 nothing provides an interface throughwhich the user can move the signals together to overlay on one another.For example, the user may be able to drag the respiration signal downonto the plethysmographic signal using a touch screen interface.Conversely, the user may be able to separate the signals, also using thetouch screen interface. In another embodiment, the monitor includes abutton the user can press, or some other user interface allowing theuser to overlay and separate the signals, as desired. FIGS. 21A and 21Bshow similar separation and joining of the signals.

In certain configurations, in addition to providing the visualcorrelation between the plethysmographic signal and the respiratorysignal, the monitor is additionally configured to process therespiratory signal and the plethysmographic signal to determine acorrelation between the two signals. For example, the monitor mayprocess the signals to determine whether the peaks and valleys in thechanges in the envelope and/or baseline of the plethysmographic signalcorrespond to bursts in the respiratory signal. And, in response to thedetermining that there is or is not a threshold level of correlation,the monitor may provide some indication to the user. For example, themonitor may provide a graphical indication (e.g., a change in color ofpleth variability index indicator), an audible alarm, or some otherindication. The monitor may employ one or more envelope detectors orother appropriate signal processing componentry in making thedetermination.

In certain embodiments, the system may further provide an audibleindication of the patient's breathing sounds instead of, or in additionto the graphical indication. For example, the monitor may include aspeaker, or an earpiece (e.g., a wireless earpiece) may be provided tothe monitoring personnel providing an audible output of the patientsounds. Examples of sensors and monitors having such capability aredescribed in U.S. Pat. Pub. No. 2011/0172561 and are incorporated byreference herein.

In addition to the above described benefits, providing both the acousticand plethysmographic signals on the same display in the manner describedcan allow monitoring personnel to more readily detect respiratory pauseevents where there is an absence of breathing, high ambient noise thatcan degrade the acoustic signal, improper sensor placement, etc.

FIGS. 22A-22B illustrate exemplary analog display indicia, according toan embodiment of the disclosure. As shown in FIGS. 22A and 22B, thescreen shots displays health indicators of various physiologicalparameters, in addition to other data. Each health indicator can includean analog indicator and/or a digital indicator. In embodiments where thehealth indicator includes an analog and a digital indicator, the analogand digital indicators can be positioned in any number of formations,such as side-by-side, above, below, transposed, etc. In the illustratedembodiment, the analog indicators are positioned above and to the sidesof the digital indicators. As shown more clearly in FIG. 22B, the analogdisplays may include colored warning sections, dashes indicatingposition on the graph, and digital information designating quantitateinformation form the graph. In FIG. 22B, for example, the pulse rate PRgraph shows that from about 50 to about 140 beats per minute, the graphis either neutral or beginning to be cautionary, whereas outside thosenumbers the graph is colored to indicate a severe condition. Thus, asthe dash moves along the arc, a caregiver can readily see where in therange of acceptable, cautionary, and extreme the current measurementsfall.

Each analog indicator of the health indicator can include a dial thatmoves about an arc based on measured levels of monitored physiologicalparameters. As the measured physiological parameter levels increase thedial can move clockwise, and as the measured physiological parameterlevels decrease, the dial can move counter-clockwise, or vice versa. Inthis way, a user can quickly determine the patient's status by lookingat the analog indicator. For example, if the dial is in the center ofthe arc, the observer can be assured that the current physiologicalparameter measurements are normal, and if the dial is skewed too far tothe left or right, the observer can quickly assess the severity of thephysiological parameter levels and take appropriate action. In otherembodiments, normal parameter measurements can be indicated when thedial is to the right or left, etc.

In some embodiments, the dial can be implemented as a dot, dash, arrow,or the like, and the arc can be implemented as a circle, spiral,pyramid, or other shape, as desired. Furthermore, the entire arc can belit up or only portions of the arc can be lit up based on the currentphysiological parameter measurement level. Furthermore, the arc can turncolors or be highlighted based on the current physiological parameterlevel. For example, as the dial approaches a threshold level, the arcand/or dial can turn from green, to yellow, to red, shine brighter,flash, be enlarged, move to the center of the display, or the like.

Different physiological parameters can have different thresholdsindicating abnormal conditions. For example, some physiologicalparameters may upper a lower threshold levels, while others only have anupper threshold or a lower threshold. Accordingly, each health indicatorcan be adjusted based on the physiological parameter being monitored.For example, the SpO2 health indicator can have a lower threshold thatwhen met activates an alarm, while the respiration rate health indicatorcan have both a lower and upper threshold, and when either is met analarm is activated. The thresholds for each physiological parameter canbe based on typical, expected thresholds and/or user-specifiedthresholds.

The digital indicator can provide a numerical representation of thecurrent levels of the physiological parameter the digital indicator mayindicate an actual level or a normalized level and can also be used toquickly asses the severity of a patient condition. In some embodiments,the display includes multiple health indicators for each monitoredphysiological parameter. In certain embodiments, the display includesfewer health indicators than the number of monitored physiologicalparameters. In such embodiments, the health indicators can cycle betweendifferent monitored physiological parameters.

FIGS. 23A-23F illustrate exemplary displays of measurement data showing,for example, data presentation in FIGS. 23A-23D when a depth ofconsciousness monitor is connected to a channel port of the hub ofFIG. 1. As shown in FIGS. 23A-23C, the hub 100 advantageously roughlybifurcates its display 104 to show various information from the, forexample, SEDLine device, commercially available from Masimo Corp. ofIrvine, Calif. In FIG. 23D, the hub 100 includes an attached Phaselndevice, commercially available by PHASEIN AB of Sweden, providing, forexample, information about the patient's respiration. The hub 100 alsoincludes the SEDLine information, so the hub 100 has divided the display104 appropriately. In FIG. 23E, temperature and blood pressure sensorscommunicate with the hub of FIG. 1 and the hub 100 creates display realestate appropriate for the same. In FIG. 23F, an acoustic sensor is alsocommunicating with the hub of FIG. 1, as well as the forgoing bloodpressure and temperature sensor. Accordingly, the hub 100 adjust thedisplay real estate to accommodate the data from each attached device.

The term “and/or” herein has its broadest least limiting meaning whichis the disclosure includes A alone, B alone, both A and B together, or Aor B alternatively, but does not require both A and B or require one ofA or one of B. As used herein, the phrase “at least one of” A, B, “and”C should be construed to mean a logical A or B or C, using anon-exclusive logical or.

The term “plethysmograph” includes it ordinary broad meaning known inthe art which includes data responsive to changes in volume within anorgan or whole body (usually resulting from fluctuations in the amountof blood or air it contains).

III. Additional Monitoring Environment Embodiments

FIG. 24 illustrates another embodiment of a monitoring environment 2000including the hub 100 of FIG. 1. The monitoring environment 2000 mayinclude all the features of the monitoring environment 200 of FIG. 2, aswell as any of the other features described above. In addition, themonitoring environment 2000 depicts another embodiment of themulti-patient monitoring system 204, namely, the multi-patientmonitoring system (MMS) 2004. The MMS 2004 includes a translation module2005 that can receive serial data, translate the serial data into aformat recognizable by the monitoring hub 100, and provide the serialdata to the monitoring hub 100 (among possibly other devices). Alsoshown is an auxiliary device 2040 that may communicate with the MMS2004, the monitoring hub 100, or the PPM 102, wired or wirelessly.

As described above, the hub 100 may receive serial data from a varietyof medical equipment, including the patient's bed 214, infusion pumps216, a ventilator 218, and other vital signs monitors 220. The hub 100can pass serial data from these sources on to the MMS 2004. As describedabove, the MMS 2004 may then store the serial data in a caregiverbackend system 206 such as an EMR system or ADT system.

The medical equipment providing this serial data may use a variety ofdifferent proprietary protocols, messaging infrastructure, and the likethat may not be natively recognizable by the hub 100. Accordingly, thehub 100 may not have native capability to read parameter values or otherdata from this medical equipment, and as a result, may not have thecapability to display parameter values or other data from these devices.Advantageously, however, the translation module 2005 at the MMS 2004 canreceive serial data from these devices, translate the serial data into aformat recognizable by the monitoring hub 100, and provide the serialdata to the monitoring hub 100. The monitoring hub 100 can then readparameter values and other data from the translated information andoutput these values or data to a display, such as any of the displaysdescribed above.

In an embodiment, the translation module 2005 applies one or moretranslation rules to the serial data to translate or transform theserial data from one format to another format. The serial data may beformatted according to a Health Level Seven (“HL7”) protocol in oneembodiment. The HL7 protocol has been developed to provide a messagingframework for the communication of clinical messages between medicalcomputer systems and devices. However, the HL7 standard is quiteflexible and merely provides a framework of guidelines. Consequently,medical devices or clinical computer systems that are all HL7-compliantmay still be unable to communicate with each other. For example, themedical equipment 214-220 may each implement a version of the HL7protocol, but these implementations may be different from an HL7protocol implemented by the monitoring hub 100. Accordingly, themonitoring hub 100 may not be able to parse or read messages from themedical equipment 214-220, even though both use the HL7 standard.Further, the translation module 2005 may translate between differentimplementations of a common standard other than the HL7 protocolimplemented by the hub 100 and medical equipment 214-220 in someembodiments.

In addition to translating between different implementations of a commonelectronic medical communication protocol (e.g., different formatting ofHL7 messages), the translation module 2005 can also translate betweeninput and output messages adhering to different communication protocols.In some embodiments, the translation module 2005 is capable ofresponding to and translating messages from, for example, one medicalcommunication protocol to a separate medical communication protocol. Forexample, the translation module 2005 can facilitate communicationbetween messages sent according to the HL7 protocol, the ISO 11073protocol, other open protocols, or proprietary protocols. Accordingly,the translation module 2005 can translate an input message sentaccording to the HL7 protocol to an output message according to adifferent protocol, or vice-versa. In certain embodiments, thetranslation module 2005 can implement any of the translation featuresdescribed below in greater detail under the section entitled“Translation Module Embodiments,” as well as further in U.S. applicationSer. No. 14/032,132, filed Sep. 19, 2013, titled “Medical MonitoringSystem,” the disclosure of which is hereby incorporated by reference inits entirety.

Advantageously, in certain embodiments, the translation module 2005 canpass translated serial data back to the hub 100 or PPM 102. Since thetranslated data is in a format readable by the hub 100 or PPM 102, thehub 100 or PPM 102 can output the data from the medical equipment214-220 on the display of the hub 100 or PPM 102. In addition, thetranslation module 2005 can provide the translated data to devices otherthan the hub 100, including clinician devices (such as cell phones,tablets, or pagers) and an auxiliary device 2040 that will be describedbelow. Moreover, since the serial data provided by the medical equipment214-220 may include alarm notifications, the translation module 2005 canpass these alarm notifications to the hub 100 or PPM 102. The hub 100 orPPM 102 can therefore generate visual or audible alarms responsive tothese alarm notifications. Further, the translation module 2005 canprovide the alarm notifications to clinician devices, e.g., over ahospital network or wide area network (such as the Internet). Inaddition, the translation module 2005 can provide the alarmnotifications to the auxiliary device 2040.

The translation module 2005 is shown as implemented in the MMS 2004because it may be beneficial to maintain and update the translationrules of the translation module 2005 in a single location. However, inother embodiments, the translation module 2005 may also be (or insteadbe) implemented in the hub 100 or PPM 102. Accordingly, the hub 100 orPPM 102 can access an internal translation module 2005 to translateserial data for output to the display of the hub 100 or PPM 102.

The auxiliary device 2040 can be a computing device having physicalcomputer hardware, a display, and the like. For example, the auxiliarydevice 2040 may be a handheld computing device used by a clinician, suchas a tablet, laptop, cellphone or smartphone, personal digital assistant(PDA), a wearable computer (such as a smart watch or glasses), or thelike. The auxiliary device 2040 may also be simply a display device,such as a computer monitor or digital television. In an embodiment, theauxiliary device 2040 provides second screen functionality for the hub100, PPM 102, or MMS 2004. As such, the auxiliary device 2040 cancommunicate wirelessly or through a wired connection with the hub 100,MMS 2004, or PPM 102.

As a second screen device, the auxiliary device 2040 can depict a copyof at least a portion of the display of the hub 100 (or the PPM 102) ora different version of the hub 100 (or the PPM 102) display. Forinstance, the auxiliary device 2040 can receive physiological parameterdata, trend data, or waveforms from the hub 100, PPM 102, or MMS 2040and display the parameter data, trend data, or waveforms. The auxiliarydevice 2040 can output any information available to the hub 100, PPM102, or MMS 2004. One use of the auxiliary device 2040 is as a cliniciandevice usable by a clinician to view data from the hub 100, PPM 102, orMMS 2004 while away from a patient's room (or even while in a patient'sroom). A clinician can use the auxiliary device 2040 to view moredetailed information about physiological parameters than is displayed onthe hub 100 or PPM 102 in an embodiment (see, e.g., FIG. 39). Forinstance, the auxiliary device 2040 may include zoom functionality orthe like that enables a clinician to zoom into trends or waveforms tomore closely inspect parameter activity.

One example reason for copying at least a portion of the display of thehub 100 or PPM 102 is to enable different clinicians to have the sameview of the data during a surgical procedure. In some surgicalprocedures, for instance, two anesthesiologists monitor a patient, oneanesthesiologist monitoring the brain function and brain oxygenation ofthe patient, while the other monitors peripheral oxygenation of thepatient. A brain sensor, such as has been described above, may beattached to the patient and provide brain monitoring and oxygenationdata that is output to the hub 100 or the PPM 102 for presentation tothe first anesthesiologist. A finger or toe/foot optical sensor can alsobe attached to the patient and output data to the hub 100 or PPM 102.The hub 100 or PPM 102 can transmit this data to the auxiliary device2040, which the second anesthesiologist can monitor to observeoxygenation in the patient's peripheral limbs. The secondanesthesiologist may also need to know the oxygenation at the brain tohelp interpret the seriousness or lack thereof of poor peripheraloxygenation values. However, in many surgical procedures, a curtain orscreen is placed over the patient as part of the procedure, blocking thesecond anesthesiologist's view of the hub 100 or PPM 102. Accordingly,the hub 100 or PPM 102 can output a copy of at least a portion of itsdisplay to the auxiliary device 2040 so that the second anesthesiologistcan monitor brain function or oxygenation.

In one embodiment, the auxiliary device has a larger display area thanthe display of the hub 100. For instance, the hub 100 may have arelatively smaller display, such as about 10 inches, while the auxiliarydevice 2040 may be a television monitor or the like that has a 40 inchor larger display (although any size display may be used for theauxiliary device 2040). In an embodiment, the auxiliary device 2040 as atelevision can include a hardware module that includes a processor,memory, and a wireless or wired networking interface or the like. Theprocessor can execute programs from the memory, including programs fordisplaying physiological parameters, trends, and waveforms on thedisplay of the television. Since a television monitor is larger thanembodiments of the hub 100, the television monitor version of theauxiliary device 2040 can display more fine detail of patient waveformsand trends in some embodiments (see, e.g., FIG. 39).

In another embodiment, the auxiliary device 2040 may display one portionof any of the displays described herein while the hub 100 displaysanother portion thereof. For instance, the auxiliary device 2040 maydisplay any of the anatomical graphics described above with respect toFIGS. 19A-19J, while the hub 100 displays any of the parameter displaysdescribed above with respect to FIGS. 20A-23F (or vice versa). Likewise,the auxiliary device 2040 may display the translated data received fromthe translation module 2005 while the hub 100 displays channel data (orvice versa). In another embodiment, the auxiliary device 2040 candisplay both translated data and channel data (see, e.g., FIG. 38).

In still other embodiments, the auxiliary device 2040 can perform atleast some processing of physiological parameters, including any of thefunctionality of the monitoring hub 100. For instance, the auxiliarydevice 2040 may include the translation module 2005 and perform thefeatures thereof.

FIG. 25 illustrates an embodiment of a translation message handlingprocess 2100. The process 2100 can be implemented by the translationmodule 2005 described above or by any other computing system. In anembodiment, at block 2502, the translation module 2005 receives amessage from the hub 100 (or PPM 102) that includes a message from amedical device not natively compatible with the hub 100 (or PPM 102). Atblock 2504, the translation module 2005 translates the message based onone or more translation rules to produce a translated output messagethat can be processed by the hub 100 (or PPM 102). At block 2506, thetranslation module provides the translated output message to the hub 100for display at the hub 100 (or PPM 102) or at an auxiliary device 2040.The hub 100 (or PPM 102) may route the translated data to the auxiliarydevice 2040, or the auxiliary device 2040 may receive the translateddata directly from the translation module 2005.

For example, in one embodiment, a first medical device having digitallogic circuitry receives a physiological signal associated with apatient from a physiological sensor, obtains a first physiologicalparameter value based on the physiological signal, and outputs the firstphysiological parameter value for display. The first medical device canalso receive a second physiological parameter value from a secondmedical device other than the first medical device, where the secondphysiological parameter value is formatted according to a protocol notused by the first medical device, such that the first medical device isnot able to process the second physiological parameter value to producea displayable output value. The first medical device can pass thephysiological parameter data from the first medical device to a separatetranslation module, receive translated parameter data from thetranslation module at the first medical device, where the translatedparameter data is able to be processed for display by the first medicaldevice, and output a second value from the translated parameter data fordisplay. The first medical device may be, for example, the hub 100, PPM102, or MMS 2004, and the second medical device may be the infusion pump216 or ventilator 218 or the like.

FIGS. 26-38 and 46-71 illustrate additional example hub displays,including displays of measurement data. Each of these displays may beimplemented by the auxiliary device 2040, although similar displays mayalso be output on the hub 100 (or PPM 102) directly. The example Figuresshown are depicted as being implemented for a tablet computer thatincludes touchscreen functionality. Touchscreen functionality isoptional and be replaced by other suitable input devices, such askeyboards, mice, track wheels, and the like.

Turning to FIG. 26, the user interface shown depicts a device connectedto the auxiliary device 2040. The device shown is “Omar's Hawk,” whichcan be an embodiment of the monitoring hub 100. The auxiliary device2040 is connected wirelessly to the hub 100 in this embodiment so as toreceive data from the hub 100. The auxiliary device could also connectwirelessly to the MMS 2004 or PPM 102 in other embodiments.

FIG. 27 depicts a default parameter view on the auxiliary device 2040.Parameter values are shown together with waveforms in an upper portionof the display, and other parameters (such as SpHb, SpMet, PVI, etc.)are shown at the bottom of the display without their correspondingwaveforms. Any of these parameters at the bottom of the display may bedragged and dropped onto the upper portion of the display to cause theirwaveforms to be shown. For instance, FIG. 28 depicts a similar displayas in FIG. 27 except that the SpHb parameter has been dragged anddropped onto the upper portion of the display, causing the SpHb waveformand additional details on alarm limits (18 and 7) to be shown.Similarly, FIG. 29 shows the same display as FIG. 28 except that theSpMet parameter has been dragged and dropped on the upper portion of thedisplay, causing its waveform and alarm limit (3) to be shown.

In each of the displays of FIGS. 27-29, a time window button is shown inthe upper right corner. This time window button says “1 hr” in FIGS.27-29 but may be selected by a user to change the time window, which canaffect the window of trend or waveform data shown in the display. A userselection of this time window button and change to a 10 minute window isshown in FIG. 30. As can be seen, the waveforms in FIG. 30 are shown ina smaller window of time than in the previous Figures.

FIG. 31 shows another version of the display of FIG. 29 with stackedwaveforms, including a stacked SpO2 and respiratory waveform, similar toother stacked waveforms described elsewhere herein. FIG. 32 shows asimilar display to FIG. 29 with the pulse rate (PR) and SpMet(methemoglobin) parameters highlighted as being in alarm condition. Thealarm condition can be represented as a red box around the parametervalues and waveforms in an embodiment, or with red transparency coloringat least a portion of the box. The red box or transparency may alsoflash in an embodiment, and an audible alarm may sound. Other ways torepresent an alarm condition are used in other embodiments.

FIG. 33 shows a popup interface that enables a user to adjust alarmlimits for a parameter (in this embodiment, SpHb or total hemoglobin).The popup interface includes scroll wheels that allow a user to quicklyscroll among and select possible parameter limit values.

FIGS. 34-38 show landscape display views in contrast to theportrait-oriented displays of FIGS. 26-33. These landscape display viewsmay be accessed by rotating the auxiliary device 2040 (such as tabletetc.) to a landscape orientation. FIG. 34 shows a first set ofparameters, while FIGS. 35 and 36 add additional drag-and-droppedparameters with their waveforms and additional alarm limit details,similar to those described above with respect to FIGS. 27-29. FIG. 37depicts stacked parameter waveforms, stacking SpO2 and respiratorywaveforms. FIG. 38 depicts both channel parameters (such as SpO2, PR(pulse rate), and RRa (acousticly-measured respiratory rate)) while alsoshowing translated serial data parameters 2210, including parametersfrom a pump and a vent. These translated serial data parameters 2210 mayhave been received from the translation module 2005, either through thehub 100 or directly from the MMS 2004.

Referring again to FIG. 24, as described above, the hub 100 or PPM 102can output a copy of at least a portion of the display to the auxiliarydevice 2040. In other embodiments, the hub 100 or PPM 102 can outputdata with respect to a subset of the full parameters shown on the hub100 or PPM 102 to the auxiliary device 2040. For instance, the hub 100or PPM 102 may provide functionality for a clinician to select one ormore of the parameters displayed thereon to see just that one or moreparameters displayed on the auxiliary device 2040. Doing so may allowthe auxiliary device 2040 to show more detail about the selected one ormore parameters because fewer parameters may be shown on the auxiliarydevice's 2040 display than on the hub 100 or PPM 102.

FIG. 39 depicts one example display of an auxiliary device 2040 thatdepicts data with respect to one parameter, respiratory rate. Unlike themain display of the hub 100 or PPM 102, the display shown in FIG. 39includes more than just the current value 2215, a recent trend 2230, andsmall waveform of the respiratory rate. In addition, the display depictsa histogram 2220 of historical highs and lows (e.g., for the pastseveral days) of the patient being monitored. In addition, a detailedwaveform 2240 is shown, which may be larger than the waveforms shown onthe main display of the hub 100 or PPM 102, which may give the user moredetailed insight into the patient's respiratory condition. A user maychoose to zoom into the waveform 2240 (or other aspects of the display),causing the waveform 2242 to be enlarged to fill the display in place ofthe other elements of the display, or the like. Other graphs, tables,waveforms, and data may be shown for the respiratory parameter on theauxiliary device display 2040. Of course, parameters other thanrespiratory rate may also be selected for detailed display on theauxiliary device 2040.

IV. Translation Module Embodiments

Any of the following features described with respect to FIGS. 40Athrough 45D can be implemented by the translation module 2005 of FIG. 24or together with any of the devices described above with respect to FIG.24.

Healthcare costs have been increasing and the demand forreasonably-priced, high-quality patient care is also on the rise. Healthcare costs can be reduced by increasing the effectiveness of hospitalinformation systems. One factor which may affect the efficacy of ahealth institution is the extent to which the various clinical computersystems employed at the health institution can interact with one anotherto exchange information.

Hospitals, patient care facilities, and healthcare providerorganizations typically include a wide variety of different clinicalcomputer systems for the management of electronic healthcareinformation. Each of the clinical computer systems of the overall IT ormanagement infrastructure can help fulfill a particular category oraspect of the patient care process. For example, a hospital can includepatient monitoring systems, medical documentation and/or imagingsystems, patient administration systems, electronic medical recordsystems, electronic practice management systems, business and financialsystems (such as pharmacy and billing), and/or communications systems,etc.

The quality of care in a hospital or other patient care facility couldbe improved if each of the different clinical computer systems acrossthe IT infrastructure (or even within the same hospital room; see, e.g.,FIGS. 1 and 24) were able to effectively communicate with each other.This could allow for the exchange of patient data that is collected byone clinical computer system with another clinical computer system thatcould benefit from such patient data. For example, this may allowdecisions relating to patient care to be made, and actions to be taken,based on a complete analysis of all the available information.

In current practice, individual clinical computer systems can be, andoften are, provided by different vendors. As a result, individualclinical computer systems may be implemented using a proprietary networkor communication infrastructure, proprietary communication protocols,etc.; the various clinical computer systems used in the hospital cannotalways effectively communicate with each other.

Medical device and medical system vendors sometimes develop proprietarysystems that cannot communicate effectively with medical devices andsystems of other vendors in order to increase their market share and toupsell additional products, systems, and/or upgrades to the healthcareprovider. Thus, healthcare providers are forced to make enterprise orsystem-wide purchase decisions, rather than selecting the besttechnology available for each type of individual clinical computersystem in use.

One example where this occurs is in the area of life-saving technologyavailable for patient monitoring. For example, many different bedsidedevices for monitoring various physiological parameters are availablefrom different vendors or providers. One such provider may offer abest-in-class device for monitoring a particular physiologicalparameter, while another such provider may offer the best-in-classdevice for another physiological parameter. Accordingly, it may bedesirable in some circumstances for a hospital to have the freedom touse monitoring devices from more than one manufacturer, but this may notbe possible if devices from different manufacturers are incapable ofinterfacing and exchanging patient information. Accordingly, the abilityto provide reasonably-priced, high-quality patient care can becompromised. In addition, since each hospital or patient care facilitymay also implement its own proprietary communication protocols for itsclinical computer network environment, the exchange of information canbe further hindered.

As described above, the Health Level Seven (“HL7”) protocol has beendeveloped to provide a messaging framework for the communication ofclinical messages between medical computer systems and devices. The HL7communication protocol specifies a number of standards, guidelines, andmethodologies which various HL7-compliant clinical computer systems canuse to communicate with each other.

The HL7 communication protocol has been adopted by many medical devicemanufacturers. However, the HL7 standard is quite flexible, and merelyprovides a framework of guidelines (e.g., the high-level logicalstructure of the messages); consequently, each medical device or medicalsystem manufacturer or vendor may implement the HL7 protocol somewhatdifferently while still remaining HL7-compliant. For example, the formatof the HL7 messages can be different from implementation toimplementation, as described more fully herein. In some cases, the HL7messages of one implementation can also include information content thatis not included in messages according to another HL7 implementation.Accordingly, medical devices or clinical computer systems that are allHL7-compliant still may be unable to communicate with each other.

Consequently, a translation module can be provided that can improve thecommunication of medical messages between medical devices or systemsthat use different allowed implementations of an establishedcommunication protocol (e.g., HL7), thereby increasing the quality ofpatient care through the integration of multiple clinical computersystems.

FIG. 40A illustrates a first medical device 2405 and a second medicaldevice 2410 that communicate with one another via a translation module2415. The first medical device 2405 is configured to transmit andreceive messages according to a first allowed format or implementationof an accepted electronic medical communication protocol, while thesecond medical device 2410 is configured to transmit and receivemessages according to a second allowed format or implementation of theelectronic medical communication protocol. In some embodiments, thefirst and second protocol formats are different implementations of theHL7 communication protocol. Other electronic medical communicationprotocols besides HL7 can also be used.

The translation module 2415 receives input messages having the firstprotocol format from the first medical device 2405 and generates outputmessages to the second medical device 2410 having the second protocolformat. The translation module 2415 also receives input messages havingthe second protocol format from the second medical device 2410 andgenerates output messages to the first medical device 2405 having thefirst protocol format. Thus, the translation module 2415 can enable thefirst and second medical devices 2405, 2410 to effectively andseamlessly communicate with one another without necessarily requiringmodification to the communication equipment or protocol implemented byeach device.

In certain embodiments, the translation module 2415 determines theprotocol format expected by an intended recipient of the input messagebased on, for example, the information in the input message or byreferencing a database that stores the protocol format used by variousdevices, and then generates the output message based on the protocolformat used by the intended recipient device or system. The outputmessage can be generated based upon a comparison with, and applicationof, a set of translation rules 2420 that are accessible by thetranslation module 2415.

The translation rules 2420 can include rules that govern how to handlepossible variations between formatting implementations within a commonprotocol. Examples of variations in formatting implementation of anelectronic medical communication protocol include, for example, thedelimiter or separator characters that are used to separate data fields,whether a particular field is required or optional, the repeatability ofportions of the message (e.g., segments, fields, components,sub-components), the sequence of portions of the message (e.g., theorder of fields or components), whether a particular portion of amessage is included, the length of the message or portions of themessage, and the data type used for the various portions of the message.

In certain embodiments, the translation rules 2420 define additions,deletions, swappings, and/or modifications that should be performed inorder to “translate” an input message that adheres to a first HL7implementation into an output message that adheres to a second HL7implementation. The output message can have, for example, differentformatting than the input message, while maintaining all, or a portionof, the substance or content of the input message.

In addition to translating between different implementations of a commonelectronic medical communication protocol (e.g., different formatting ofHL7 messages), the translation module 2415 can also translate betweeninput and output messages adhering to different communication protocols.In some embodiments, the translation module 2415 is capable ofresponding to and translating messages from, for example, one medicalcommunication protocol to a separate medical communication protocol. Forexample, the translation module 2415 can facilitate communicationbetween messages sent according to the HL7 protocol, the ISO 11073protocol, other open protocols, and/or proprietary protocols.Accordingly, an input message sent according to the HL7 protocol can betranslated to an output message according to a different protocol, orvice-versa.

The operation of the translation module 2415 and the translation rules2420 will be described in more detail below. Various embodiments ofsystem architectures including the translation module 2415 will now bedescribed.

In certain embodiments, the first medical device 2405, the secondmedical device 2410, and the translation module 2415 are communicativelycoupled via connection to a common communications network or directly(via cables or wirelessly), for example, through the hub 100, PPM 102,and/or MMS 2004. In some embodiments, the translation module 2415 can becommunicatively coupled between the first medical device 2405 and thesecond medical device 2410 (with or without a communications network)such that all messages between the first and second medical devices2405, 2410 are routed through the translation module 2415. Otherarchitectures are also possible.

The first and second medical devices 2405, 2410 and the translationmodule 2415 can be included in, for example, a portion of the monitoringenvironments of FIG. 1 or 24 described above. The first medical device2405 may be, for example, the infusion pump(s) 216 or ventilator 218,while the second medical device 2410 may be, for example, the monitoringhub 100, PPM 102, MMS 2004, or auxiliary device 2040. The translationmodule 2415 is an example implementation of the translation module 2005.

In certain embodiments, the translation module 2415 can facilitatecommunication across multiple networks within a hospital environment. Inother embodiments, the translation module 2415 can facilitatecommunication of messages across one or more networks extending outsideof the hospital or clinical network environment. For example, thetranslation module 2415 can provide a communications interface withbanking institutions, insurance providers, government institutions,outside pharmacies, other hospitals, nursing homes, or patient carefacilities, doctors' offices, and the like.

In some embodiments, the translation module 2415 of FIG. 40 can be acomponent of, for example, the environment 2000 described above withrespect to FIG. 24. For example, the translation module 2415 can becommunicatively coupled with a hospital network or other networks ormonitoring environments described above. In such embodiments, thetranslation module 2415 can facilitate the exchange of patientmonitoring information, including, for example, physiological parametermeasurements, physiological parameter trend information, andphysiological parameter alarm conditions between bedside medical monitordevices, nurses' monitoring stations, a Hospital or Clinical InformationSystem (which may store Electronic Medical Records), and/or many othermedical devices and systems. The translation module 2415 can enableseamless communication between different medical devices and systems,each of which may use a different implementation of an electronicmedical communication protocol such as, for example, the HL7communication protocol, within a clinical or hospital networkenvironment.

In certain embodiments, the translation module 2415 can also facilitatecommunication between a first medical device that is part of the patientmonitoring sub-system and a second medical device that is not part of,or is external to, the patient monitoring system 200. As such, thetranslation module 2415 can be capable of responding toexternally-generated medical messages (such as patient informationupdate messages, status query messages, and the like from an HIS or CIS)and generating external reporting messages (such as event reportingmessages, alarm notification messages, and the like from patientmonitors or nurses' monitoring stations).

In another embodiment, first and second medical devices 2405, 2410communicate with each other over a communication bus 2421. Communicationbus 2421 can include any one or more of the communication networks,systems, and methods described above, including the Internet, a hospitalWLAN, a LAN, a personal area network, etc. For example, any of thenetworks describe above can be used to facilitate communication betweena plurality of medical devices, including first and second medicaldevices 2405, 2410, discussed above. One such embodiment is illustratedin FIG. 40B.

In FIG. 40B, first medical device 2405 provides a message to thecommunication bus 2421. The message is intended for receipt by thesecond medical device 2410; however, because first and second medicaldevices 2405, 2410 communicate according to different communicationprotocol format, second medical device 2410 is unable to process themessage.

Translation module 2415 monitors the communication bus 2421 for suchmessages. Translation module receives the message and determines thatfirst medical device 2405 is attempting to communicate with secondmedical device 2410. Translation module 2415 determines that messagetranslation would facilitate communication between first and secondmedical devices 2405, 2410. Translation module 2415 therefore utilizesan appropriate translation rule stored in a translation module 2420.Translation module 2420 can include a memory, EPROM, RAM, ROM, etc.

The translation module 2415 translates the message from the firstmedical device 2405 according to any of the methods described herein.Once translated, the translation module 2415 delivers the translatedmessage to the communication bus 2421. The second medical device 2410receives the translated message and responds appropriately. For example,the second medical device may perform a function and/or attempt tocommunication with the first medical device 2405. The translation module2415 facilitates communication from the second medical device 2410 tothe first medical device 2405 in a similar manner.

The first medical device 2405 and the second medical device 2410 can be,for example, any of the medical devices or systems communicativelycoupled to a hospital network or hub 100, PPM 102, and/or MMS 2004.These medical devices or systems can include, for example, point-of-caredevices (such as bedside patient monitors), data storage units orpatient record databases, hospital or clinical information systems,central monitoring stations (such as a nurses' monitoring station),and/or clinician devices (such as pagers, cell phones, smart phones,personal digital assistants (PDAs), laptops, tablet PCs, personalcomputers, pods, and the like).

In some embodiments, the first medical device 2405 is a patient monitorfor communicatively coupling to a patient for tracking a physiologicalparameter (e.g., oxygen saturation, pulse rate, blood pressure, etc.),and the second medical device 2410 is a hospital information system(“HIS”) or clinical information system (“CIS”). In some embodiments, thepatient monitor can communicate physiological parameter measurements,physiological parameter alarms, or other physiological parametermeasurement information generated during the monitoring of a patient tothe HIS or CIS for inclusion with the patient's electronic medicalrecords maintained by the HIS or CIS.

In some embodiments, the first medical device 2405 is an HIS or CIS andthe second medical device 2410 is a nurses' monitoring station, asdescribed herein. However, the translation module 2415 can facilitatecommunication between a wide variety of medical devices and systems thatare used in hospitals or other patient care facilities. For example, thetranslation module 2415 can facilitate communication between patientphysiological parameter monitoring devices, between a monitoring deviceand a nurses' monitoring station, etc.

Using the translation module 2415, a patient monitoring sub-system, suchas those described herein (e.g., physiological monitoring system 200),can push data to the HIS or pull data from the HIS even if the HIS usesa different implementation of the HL7 protocol, or some other electronicmedical communication protocol.

In certain embodiments, the patient monitoring sub-system can beconfigured to push/pull data at predetermined intervals. For example, apatient monitor or clinician monitoring station can download patientdata automatically from the HIS at periodic intervals so that thepatient data is already available when a patient is connected to apatient monitor. The patient data sent from the HIS can includeadmit/discharge/transfer (“ADT”) information received upon registrationof the patient. ADT messages can be initiated by a hospital informationsystem to inform ancillary systems that, for example, a patient has beenadmitted, discharged, transferred or registered, that patientinformation has been updated or merged, or that a transfer or dischargehas been canceled.

In other embodiments, the patient monitoring sub-system can beconfigured to push/pull data to/from the HIS only when the HIS issolicited by a query. For example, a clinician may make a request forinformation stored in a patient's electronic medical records on the HIS.

In still other embodiments, the patient monitoring sub-system can beconfigured to push/pull data to/from the HIS in response to anunsolicited event. For example, a physiological parameter of a patientbeing monitored can enter an alarm condition, which can automatically betransmitted to the HIS for storing in the patient's electronic medicalrecords. In yet other embodiments, any combination of the above methodsor alternative methods for determining when to communicate messages toand from the HIS can be employed.

Example system architectures and example triggers for the communicationof messages involving the translation module 2415 have been described.Turning now to the operation of the translation module, FIGS. 25A-25Dillustrate an example medical message at different phases or steps of atranslation process. The translation process will be described in moredetail below in connection with FIGS. 26, 27A and 27B.

FIG. 41A illustrates an example ADT input message 2505 received by thetranslation module 2415 from an HIS. The ADT input message 2505 isimplemented according to the HL7 communication protocol and containsinformation related to the admission of a patient to a hospital. The ADTmessage 2505 includes multiple segments, including a message headersegment 2506, an event segment, a patient identification segment, apatient visit segment, role segments, a diagnosis segment, and multiplecustom segments.

In some embodiments, the message header (“MSH”) segment 2506 defines howthe message is being sent, the field delimiters and encoding characters,the message type, the sender and receiver, etc. The first symbol orcharacter after the MSH string can define the field delimiter orseparator (in this message, a “caret” symbol). The next four symbols orcharacters can define the encoding characters. The first symbol definesthe component delimiter (“˜”), the second symbol defines the repeatabledelimiter (“|”), the third symbol defines the escape delimiter (“\”),and the fourth symbol defines the sub-component delimiter (“&”). All ofthese delimiters can vary between HL7 implementations.

In some embodiments, the example header segment 2506 further includesthe sending application (“VAFC PIMS”), the receiving application(“NPTF-508”), the date/time of the message (“20091120104609-0600”), themessage type (“ADT˜A01”), the message control ID (“58103”), theprocessing ID (“P”), and the country code (“USA”). As represented by theconsecutive caret symbols, the header segment also contains multipleempty fields.

FIG. 41B illustrates the message header segment 2506 after it has beenparsed into fields or elements based on an identified field delimiter(the caret symbol). In certain embodiments, the parsed input messagecomprises an XML message that is configured to be transformed accordingto extensible stylesheet language transformation (XSLT) rules.

In certain embodiment, the parsed input message can be encoded. FIG. 41Cillustrates the parsed message header segment of the input message afterbeing encoded (e.g., using a Unicode Transformation Format-8 (“UTF-8”)encoding scheme).

The encoded message header segment shows some of the various data typesthat can be used in the message. For example, the sending application(“VAFC PIMS”) of the third parsed field and the receiving application(“NPTF-508”) of the fifth parsed field are represented using ahierarchic designator (“HD”) name data type. The date/time field (theseventh parsed field) is represented using the time stamp (“TS”) datatype. The processing ID field (the eleventh parsed field) is representedusing the processing type (“PT”) data type. The fields that do notinclude a data type identifier are represented using the string (“ST”)data type. Other possible data types include, for example, codedelement, structured numeric, timing quantity, text data, date, entryidentifier, coded value, numeric, and sequence identification. The datatypes used for the various fields or attributes of the segments can varybetween formatting implementations.

FIG. 41D illustrates an example output message 2510 from the translationmodule 2415 based on the example input message 2505 of FIG. 41A. Theoutput message 2510 includes a message acknowledgement segment 2512.

Turning to the operation of the translation module, the translationmodule 2415 can, for example, create, generate, or produce an outputmessage that is reflective of the input message based on an applicationof the set of translation rules 2420. In some embodiments, thetranslation module 2415 can, for example, translate, transform, convert,reformat, configure, change, rearrange, modify, adapt, alter, or adjustthe input message based on a comparison with, and application of, theset of translation rules 2420 to form the output message. In someembodiments, the translation module 2415 can, for example, replace orsubstitute the input message with an output message that retains thecontent of the input message but has a new formatting implementationbased upon a comparison with, and application of, the set of translationrules 2420.

FIG. 42 illustrates a translation process 2600 for generating an outputmessage based on an input message and a comparison with the set oftranslation rules 2420 associated with the translation module 2415. Thetranslation process 2600 starts at block 2602 where the translationmodule 2415 receives an input message from a first medical device.

At block 2604, the translation module 2415 determines the formattingimplementation of the input message and the formatting implementation tobe used for the output message. In certain embodiments, the inputmessage can include one or more identifiers indicative of the formattingimplementation. In some embodiments, the determination of the formattingimplementation can be made, for example, by analyzing the message itselfby identifying the delimiter or encoding characters used, the fieldorder, the repeatability of segments, fields, or components, the datatype of the fields, or other implementation variations. In certainembodiments, the translation module 2415 can separate or parse out theformatting from the content of the message (as shown in FIG. 41B) to aidin the determination of the formatting implementation. In someembodiments, the translation module 2415 determines the formattingimplementation of the input message by referencing a database thatstores the implementation used by each device with which the translationmodule 2415 has been configured to interface.

In certain embodiments, the determination of the formattingimplementation used by the output message can also be determined fromthe input message. For example, the input message can include a fieldthat identifies the intended recipient application, facility, system,device, and/or destination. The input message can alternatively includea field that identifies the type of message being sent (e.g., ADTmessage) and the translation module 2415 can determine the appropriaterecipient from the type of message being sent and/or the sendingapplication, device, or system. The translation module 2415 can thendetermine the formatting implementation required by the intendedrecipient of the input message.

At decision block 2605, the translation module 2415 determines whether arule set has been configured for the translation from the identifiedformatting implementation of the input message to the identifiedformatting implementation to be used for the output message. The ruleset may have been manually configured prior to installation of thetranslation module software or may have been automatically configuredprior to receipt of the input message. If a rule set has already beenconfigured, then the translation process 2600 continues to block 2606.If a rule set has not been configured, then a rule set is configured atblock 2607. The configuration of the rule set can be performed asdescribed below in connection with FIGS. 44 and 45A-2459D. Thetranslation process 2600 then continues to block 2608.

At block 2606, the translation module 2415 identifies the pre-configuredrules from the set of translation rules 2420 that govern translationbetween the determined formatting implementation of the input messageand the formatting implementation of the output message. In someembodiments, the identification of the pre-configured rules can be mademanually.

At block 2608, the translation module 2415 generates an output messagebased on the configured rule set(s) of the translation rules 2420. Incertain embodiments, the output message retains all, or at least aportion of, the content of the input message but has the format expectedand supported by the intended recipient of the input message.

The translation rules 2420 can include, for example, unidirectionalrules and/or bidirectional rules. A unidirectional rule can be one, forexample, that may be applied in the case of a message from a firstmedical device (e.g., 2405) to a second medical device (e.g., 2410) butis not applied in the case of a message from the second medical deviceto the first medical device. For example, a unidirectional rule couldhandle a difference in the delimiters used between fields for twodifferent formatting implementations of, for example, the HL7communication protocol. The translation module 2415 can apply a fielddelimiter rule to determine if the field delimiter is supported by theintended recipient of the input message. If the field delimiter of theinput message is not supported by the intended recipient, the fielddelimiter rule can replace the field delimiter of the input message witha field delimiter supported by the intended recipient.

For example, an input message from an input medical device can include aformatting implementation that uses a “caret” symbol (“̂”) as the fielddelimiter or separator. However, the formatting implementationrecognized by the intended recipient medical device may use a “pipe”symbol (“|”) as the field delimiter. The translation module 2415 canidentify the field delimiter symbol used in the formattingimplementation recognized by the intended recipient medical device fromthe set of translation rules 2420 and generate an output message basedon the input message that uses the pipe field delimiter symbol insteadof the caret field delimiter symbol used in the input message. The ruleto substitute a pipe symbol for a caret symbol would, in this case, onlyapply to messages that are sent to a recipient device that recognizesthe pipe symbol as a field delimiter. This rule could be accompanied bya complementary rule that indicates that a caret symbol should besubstituted for a pipe symbol in the case of a message that is intendedfor a recipient device that is known to recognize the caret symbol asthe field delimiter.

Another unidirectional rule can handle the presence or absence ofcertain fields between different formatting implementations. Forexample, an input message from an input medical device can includefields that would not be recognized by the intended recipient medicaldevice. The translation module 2415 can generate an output message thatdoes not include the unrecognized or unsupported fields. In situationswhere an input message does not include fields expected by the intendedrecipient medical device, the set of translation rules 2420 can includea rule to insert null entries or empty “ ” strings in the fieldsexpected by the intended recipient medical device and/or to alert therecipient device of the absence of the expected field. The sender devicemay also be notified by the translation module 2415 that the recipientdevice does not support certain portions of the message.

Other unidirectional rules can facilitate, for example, the conversionof one data type to another (for example, string (“ST”) to text data(“TX”) or structured numeric (“SN”) to numeric (“NM”)), and the increaseor decrease in the length of various portions of the message.Unidirectional rules can also be used to handle variations inrepeatability of portions of the message. For example, the translationmodule 2415 can apply a field repeatability rule to repeated instancesof a segment, field, component, or sub-component of the message todetermine how many such repeated instances are supported by therecipient device, if any, and deleting or adding any repeated instancesif necessary. For example, a phone number field of a patientidentification segment can be a repeatable field to allow for entry ofhome, work, and cell phone numbers.

Bidirectional rules can also be used. Such rules may apply equally tomessages between first and second medical devices (e.g., 2405, 2410)regardless of which device is the sender and which is the recipient. Abidirectional rule can be used to handle changes in sequence, forexample. In certain implementations, an input message from an inputmedical device can include a patient name field, or fields, in which afirst name component appears before a last name component. However, theintended recipient medical device may be expecting an implementationwhere the last name component appears before the first name component.Accordingly, the set of translation rules 2420 can include abidirectional rule to swap the order of the first and last namecomponents when communicating between the two medical devices, orbetween the two formatting implementations. In general, field orderrules can be applied to determine whether the fields, components, orsub-components are in the correct order for the intended recipient andrearranging them if necessary. Other bidirectional rules can be includedto handle, for example, other sequential variations between formattingimplementations or other types of variations.

The translation rules 2420 can also include compound rules. For example,a compound rule can include an if-then sequence of rules, wherein a rulecan depend on the outcome of another rule. Some translation rules 2420may employ computations and logic (e.g., Boolean logic or fuzzy logic),etc.

As discussed above, the messages communicated over the hospital-basedcommunication network can employ the HL7 protocol. FIGS. 43A and 43Billustrate translation processes 2700A, 2700B in which HL7 messages arecommunicated between a HIS and a medical device over a hospital-basedcommunications network or a clinical network. The translation processes2700A, 2700B will be described with the assumption that the rulesgoverning “translation” between the first and second HL7 formats havealready been configured.

FIG. 43A illustrates a translation process 2700A in which thetranslation module 2415 facilitates communication of an HL7 message,such as the ADT message of FIG. 41A, from an HIS having a first HL7format to an intended recipient medical device, such as a patientmonitor or a clinician monitoring station, having a second HL7 format.

The translation process 2700A starts at block 2701, where thetranslation module 2415 receives an input message having a first HL7format from the HIS. In certain embodiments, the input message includesinformation regarding, for example, the admission of a patient and/orpatient identification and patient medical history information from anelectronic medical records database.

At block 2703, the translation module 2415 determines the formattingimplementation of the input message and the formatting implementation tobe used for the output message. These determinations can be made in asimilar manner to the determinations discussed above in connection withblock 2604 of FIG. 42.

At block 2705, the translation module 2415 identifies the rules thatgovern translation between the determined HL7 format of the inputmessage and the HL7 format of the output message and generates an outputmessage having the second HL7 format based on the identified rules. Incertain embodiments, the output message retains the content of the inputmessage sent by the HIS but has the format expected and supported by theintended recipient of the input message.

At block 2707, the translation module 2415 can output the output messageto the intended recipient over the hospital-based communicationsnetwork. In certain embodiments, the intended recipient can transmit anacknowledgement message back to the hospital information systemacknowledging successful receipt or reporting that an error occurred.

FIG. 43B illustrates a translation process 2700B in which thetranslation module 2415 facilitates communication of an HL7 message froma medical device, such as a patient monitor, having a first HL7 formatto an HIS having a second HL7 format. For example, the patient monitorcan transmit reporting event data m such as patient alarm data, to theHIS to store in the patient's electronic medical records.

The translation process 2700B starts at block 2702, where thetranslation module 2415 receives an input message having a first HL7format from the medical device. In certain embodiments, the inputmessage includes patient monitoring data or alarm data regarding one ormore physiological parameters of the patient being monitored for storagein an electronic medical records database associated with the HIS.

At block 2704, the translation module 2415 determines the formattingimplementation of the input message and the formatting implementation tobe used for the output message. These determinations can be made in asimilar manner to the determinations discussed above in connection withblock 2604 of FIG. 42.

At block 2706, the translation module 2415 identifies the rules thatgovern translation between the determined HL7 format of the inputmessage and the HL7 format of the output message and generates an outputmessage having the second HL7 format based on the identified rules. Incertain embodiments, the output message retains the content of the inputmessage sent by the medical device but has the format expected andsupported by the HIS.

At block 2708, the translation module 2415 can output the output messageto the hospital information system over the hospital-basedcommunications network. In certain embodiments, the HIS can transmit anacknowledgement message back to the medical device acknowledgingsuccessful receipt or reporting that an error occurred.

FIGS. 42, 43A and 43B described the operation of the translator module2415. FIGS. 44 and 45A-45D will be used to illustrate the description ofthe configuration of the translation rules 2420.

The translation rules 2420 can be implemented as one or morestylesheets, hierarchical relationship data structures, tables, lists,other data structures, combinations of the same, and/or the like. Incertain embodiments, the translation rules 2420 can be stored in localmemory within the translation module 2415. In other embodiments, thetranslation rules 2420 can be stored in external memory or on a datastorage device communicatively coupled to the translation module 2415.

The translation module 2415 can include a single rule set or multiplerule sets. For example, the translation module 2415 can include aseparate rule set for each medical device/system and/or for eachpossible communication pair of medical devices/systems coupled to thenetwork or capable of being coupled to the network. In some embodiments,the translation module 2415 can include a separate rule set for eachpossible pair of formatting implementations that are allowed under amedical communication protocol such as, for example, the HL7 protocol.

In certain embodiments, the translation rules 2420 can be manuallyinputted using, for example, the messaging implementation software tool2800 illustrated in FIG. 44. For example, the software developer for aparticular hospital network can determine the protocol message formatsused by the devices and/or systems that are or can be coupled to thehospital network and then manually input rules to facilitate“translation” between the various protocol message formats supported orrecognized by the devices and/or systems.

FIG. 44 illustrates an example screenshot from a messagingimplementation software tool 2800 for manually configuring translationrules 2420 to be used by the translation module 2415. The screenshotfrom the messaging implementation software tool 2800 illustrates variousparameters that may differ between formatting implementations of anelectronic medical communication protocol, such as HL7. The screenshotalso includes areas where a user can input information that defines, oris used to define, translation rules for converting between differentHL7 implementations. In some embodiments, the messaging implementationsoftware tool 2800 stores a variety of pre-configured rule sets based,for example, on known communication protocol implementations of variousmedical devices. In such embodiments, a user may configure one or moretranslation rules 2420 to be used in communications involving suchdevices by entering identification information, such as the devicemanufacturer, model number, etc. Based on this identificationinformation, the messaging implementation tool 2800 can identify apre-configured set of translation rules for communication with thatdevice.

In other embodiments, the translation rules 2420 can be automaticallygenerated. For example, the automatic generation of a new set, ormultiple sets, of rules can be triggered by the detection of a newlyrecognized “communicating” medical device or system on a network. Incertain embodiments, the automatic generation of a new set or multiplesets of rules can occur at the time a first message is received from orsent to a new “communicating” medical device or system coupled to thenetwork. In still other embodiments, the automatic generation of rulesets includes updating or dynamically modifying a pre-existing set ofrules.

The automatic generation of translation rule sets can be carried out ina variety of ways. For example, in some embodiments, the translationmodule 2415 can automatically initiate usage of a pre-configured set oftranslation rules 2420 based upon, for example, the make and model of anew device that is recognized on the network. In certain embodiments,the translation module 2415 can request one or more messages from thenew device or system and then analyze the messages to determine the typeof formatting being implemented, as illustrated by the automatic ruleconfiguration process 2900A of FIG. 45A. The automatic ruleconfiguration process 2900A starts at block 2901, where the translationmodule 2415 receives one or more messages from a detected medical deviceor system on the network. The messages can be received upon transmissionto an intended recipient medical device or system or in response to aquery sent by the translation module 2415 or another medical device orsystem coupled to the network.

At block 2903, the translation module 2415 determines the protocol ofthe one or more received messages by, for example, analyzing the messageor by consulting a database that indicates what communicationprotocol/format is implemented by each medical device or system on thenetwork. In certain embodiments, the translation module 2415 isconfigured to handle medical messages implemented using a single commonprotocol, such as HL7. Accordingly, if a determination is made that thereceived messages are implemented using a non-supported ornon-recognized protocol, the translation module can ignore the messagesreceived from the detected medical device or system, output an alert orwarning, or allow the messages to be sent without being translated.

At block 2905, the translation module 2415 determines the formattingimplementation of the received message(s). In certain embodiments, thereceived messages can include one or more identifiers indicative of theformatting implementation. In other embodiments, the determination ofthe formatting implementation can be made, for example, by analyzing themessage itself by checking field order, the delimiter or encodingcharacters used, or other implementation variations. In certainembodiments, the translation module 2415 can separate or parse out theformatting from the content of the message to aid in the determinationof the formatting implementation.

At block 2907, the translation module 2415 configures one or more rulesor rule sets to handle messages received from and/or sent to thedetected medical device or system. In certain embodiments, theconfiguration of the rules involves the creation or generation of newrules. In other embodiments, the configuration of the rules involves thealteration or updating of existing rules. The configured rules or rulesets can be included with the translation rules 2420. If a set of rulesalready exists for the formatting implementation used by the new deviceor system, then the configuration of new translation rules may not berequired. Instead, existing translation rules can be associated with thenew device or system for use in communication involving that device orsystem. In other embodiments, the translation module 2415 can create anew set of rules geared specifically for the new device or system or canmodify an existing set of rules based on subtle formatting variationsidentified.

In other embodiments, the translation module 2415 can generate testmessage(s) that may be useful in identifying the communication protocoland implementation used by a device or system. For example, thetranslation module can generate test messages to cause the newlydetected device or system to take a particular action (e.g., storeinformation) and then query information regarding the action taken bythe newly detected device to determine whether or how the test messagewas understood. This is illustrated by the automatic rule configurationprocess 2900B of FIG. 45B.

The automatic rule configuration process 2900B starts at block 2902,where the translation module 2415 transmits one or more test, orinitialization, messages to a remote device or system detected on anetwork. The test messages can be configured, for example, to instructthe remote device or system to take a particular action (e.g., storepatient information). In certain embodiments, the test messages can beconfigured to generate a response indicative of the type of formattingrecognized or supported by the remote device or system. In otherembodiments, the test messages can be configured such that only devicesor systems supporting a particular formatting implementation willunderstand and properly act on the test messages.

At block 2904, the translation module 2415 queries the remote device orsystem to receive information regarding the action taken based on thetest message sent to the remote device or system to determine whetherthe test message was understood. For example, if the test messageinstructed the remote device or system to store patient information in aparticular location, the translation module 2415 can query theinformation from the location to determine whether the test message wasunderstood. If the test message was not understood, the translationmodule 2415 can, for example, continue sending test messages of knownformatting implementations until a determination is made that the testmessage has been understood.

At block 2906, the translation module 2415 determines the protocol andformatting implementation based on the information received. As anexample, in certain embodiments, the test message can include aninstruction to store patient name information. The test message caninclude a patient name field having a first name component followed by asurname component. The translation module 2415 can then query the remotedevice or system to return the patient surname. Depending on whether thepatient surname or the first name is returned, this query can be usefulin determining information about the order of fields in the formattingimplementation being used by the remote device or system. As anotherexample, the test messages can instruct the detected device or system tostore repeated instances of a component. The translation module 2415 canthen query the device or system to return the repeated instances to seewhich, if any, were stored. This repeatability information can also beuseful in determining whether certain fields are allowed to be repeatedin the formatting implementation being used by the remote device forsystem, and, if so, how many repeated instances are permitted.

At block 2908, the translation module 2415 configures one or more rulesto handle messages received from and/or sent to the detected medicaldevice or system. For example, the rules can convert messages from themessage format used by a first medical device to that used by a secondmedical device, as described herein. In certain embodiments, theconfiguration of the rules involves the creation or generation of newrules. In other embodiments, the configuration of the rules involves thealteration or updating of existing rules. If a set of rules alreadyexists for the formatting implementation used by the new device orsystem, then the configuration of new translation rules may not berequired. Instead, existing translation rules can be associated with thenew device or system for use in communication involving that device orsystem.

FIGS. 29C and 29D illustrate automatic rule configuration processesperformed by the translation module 2415 for messages utilizing the HL7protocol. The HL7 protocol can be used, for example, to communicateelectronic messages to support administrative, logistical, financial,and clinical processes. For example, HL7 messages can include patientadministration messages, such as ADT messages, used to exchange patientdemographic and visit information across various healthcare systems.

The automatic rule configuration process 2900C illustrated in FIG. 45Cis similar to the process 2900A illustrated in FIG. 45A. At block 2911,the translation module 2415 receives one or more messages from an HL7medical device. At block 2915, the translation module 2415 determinesthe formatting implementation of the HL7 medical device from the one ormore messages received. As discussed above, the determination of theformatting implementation can be made, for example, by checking fieldorder or sequence, field delimiter characters, repeatability,cardinality, and other HL7 implementation variations.

At block 2917, the translation module 2415 configures one or more rulesto handle messages received from and/or sent to the HL7 medical device.In certain embodiments, the configuration of the rules involves thecreation or generation of new rules for the detected formattingimplementation. In other embodiments, the configuration of the rulesinvolves the dynamic alteration or updating of existing rules. If a setof rules already exists for the formatting implementation used by thenew HL7 medical device, then the configuration of new translation rulesmay not be required. Instead, existing translation rules can beassociated with the new HL7 medical device for use in communicationinvolving that device.

The automatic rule configuration process 2900D illustrated in FIG. 45Dis similar to the process 2900B illustrated in FIG. 45B. At block 2912,the translation module 2415 transmits one or more test, dummy, orinitialization messages to an HL7 medical device. In other embodiments,the translation module 2415 can cause one or more test messages to betransmitted to the new HL7 medical device from another HL7 medicaldevice. As described above, the test messages can include messageshaving known HL7 formats configured to determine whether the HL7 deviceunderstands the test messages. The test messages can include test ADTmessages, for example.

At block 2914, the translation module 2415 queries the HL7 medicaldevice to receive information regarding an action taken or informationstored in response to the test message. At block 2916, the translationmodule 2415 determines the formatting implementation of the HL7 devicebased on the information received. In certain embodiments, thetranslation module 2415 can analyze the information received todetermine whether the test message or messages were properly understood.If none of the test messages were properly understood, the translationmodule 2415 can send additional test messages having other known HL7formats and repeat blocks 2914 and 2916.

At block 2918, the translation module 2415 configures one or moretranslation rules to handle messages received from and/or sent to thedetected HL7 medical device. In certain embodiments, the configurationof the translation rules involves the creation or generation of newtranslation rules. In other embodiments, the configuration of the rulesinvolves the alteration or updating of existing rules. If a set oftranslation rules already exists for the formatting implementation usedby the new HL7 medical device, then the configuration of new translationrules may not be required. Instead, existing translation rules can beassociated with the new HL7 medical device for use in communicationinvolving that HL7 medical device.

The automatic rule configuration processes described above can betriggered by the detection of a network device or system by thetranslation module 2415. The medical devices referred to in FIGS.45A-45D can include any of the devices or systems illustrated in FIG. 1or 24.

In some embodiments, the automatic generation of translation rules canadvantageously occur post-installation and post-compilation of themessaging sub-system software, which includes the translation module2415. In certain embodiments, the automatic generation or dynamicmodification of the translation rules 2420 can occur without having torecompile or rebuild the translation module software. This feature canbe advantageous in terms of efficiently complying with U.S. Food andDrug Administration (“FDA”) requirements regarding validation ofsoftware used in healthcare environments.

Take, for example, a situation where a medical device manufacturer plansto use the translation module 2415 to facilitate communication between aparticular medical device or system that is to be installed in ahospital (e.g., a patient monitoring system, as described herein), orother patient care facility, and other devices or systems that arealready installed at the hospital (e.g., the HIS or CIS). Any softwarerequired for the operation of the new medical device to be installed maybe at least partially validated for FDA compliance prior to installationat the hospital despite the fact that, for example, the HL7implementations of other existing devices or systems at the hospital maystill be unknown. For example, any aspects of the software for the newmedical device that are dependent upon receiving messages from otherhospital devices can be validated pre-installation as being capable offully and correctly operating when the expected message format isreceived. Then, once the medical device is installed at the hospital,the validation of the software can be completed by showing that thetranslation module 2415 is able to provide messages of the expectedformat to the newly installed device. In this way, FDA validation taskscan be apportioned to a greater extent to the pre-installation timeframewhere they can be more easily carried out in a controlled manner ratherthan in the field.

In addition, the translation module 2415 can further help streamline FDAvalidation, for example, when a medical device or system is expected tobe installed at different hospitals whose existing devices use, forexample, different implementations of the HL7 protocol. Normally, thistype of situation could impose the requirement that the entirefunctionality of the software for the new medical device be completelyvalidated at each hospital. However, if the translation module 2415 isused to interface between the new medical device and the hospital'sexisting devices, then much of the software functionality could possiblybe validated a single time prior to installation, as just described.Then, once installed at each hospital, the software validation for themedical device can be completed by validating that correct messageformats are received from the translation module (the translation rulesfor which are field-customizable). This may result in making on-sitevalidation procedures significantly more efficient, which willadvantageously enable more efficient FDA compliance in order to bringlife-saving medical technology to patients more quickly by the use offield-customizable translation rules.

V. Example Embodiments

In certain embodiments, a system for providing medical data translationfor output on a medical monitoring hub can include a portablephysiological monitor comprising a processor that can: receive aphysiological signal associated with a patient from a physiologicalsensor, calculate a physiological parameter based on the physiologicalsignal, and provide a first value of the physiological parameter to amonitoring hub for display. The monitoring hub can include a dockingstation that can receive the portable physiological monitor. Themonitoring hub can: receive the first value of the physiologicalparameter from the portable physiological monitor; output the firstvalue of the physiological parameter for display; receive physiologicalparameter data from a medical device other than the portablephysiological monitor, the physiological parameter data formattedaccording to a protocol other than a protocol natively readable ordisplayable by the monitoring hub; pass the physiological parameter datato a translation module; receive translated parameter data from thetranslation module, where the translated parameter data can be readableand displayable by the monitoring hub; and output a second value fromthe translated parameter data for display.

The system of the preceding paragraph can be combined with anysubcombination of the following features: the monitoring hub is furtherconfigured to output the first value of the physiological parameter andthe second value from the translated parameter data on separatedisplays; the monitoring hub is further configured to output the secondvalue from the translated parameter data to an auxiliary device having aseparate display from a display of the monitoring hub; the auxiliarydevice is selected from the group consisting of a television, a tablet,a phone, a wearable computer, and a laptop; the physiological parameterdata comprises data from an infusion pump; the physiological parameterdata comprises data from a ventilator; and the translation module isconfigured to translate the physiological parameter data from a firstHealth Level 7 (HL7) format to a second HL7 format.

In certain embodiments, a method of providing medical data translationfor output on a medical monitoring hub can include: under the control ofa first medical device comprising digital logic circuitry, receiving aphysiological signal associated with a patient from a physiologicalsensor; obtaining a first physiological parameter value based on thephysiological signal; outputting the first physiological parameter valuefor display; receiving a second physiological parameter value from asecond medical device other than the first medical device, where thesecond physiological parameter value is formatted according to aprotocol not used by the first medical device, such that the firstmedical device is not able to process the second physiological parametervalue to produce a displayable output value; passing the physiologicalparameter data from the first medical device to a separate translationmodule; receiving translated parameter data from the translation moduleat the first medical device, the translated parameter data able to beprocessed for display by the first medical device; and outputting asecond value from the translated parameter data for display.

The method of the preceding paragraph can be combined with anysubcombination of the following features: further including translatingthe message by at least translating the message from a first HealthLevel 7 (HL7) format to a second HL7 format; the message can includedata from a physiological monitor; the message can include data from aninfusion pump or a ventilator; and the message can include data from ahospital bed.

In certain embodiments, a system for providing medical data translationfor output on a medical monitoring hub can include a first medicaldevice including electronic hardware that can: obtain a firstphysiological parameter value associated with a patient; output thefirst physiological parameter value for display; receive a secondphysiological parameter value from a second medical device other thanthe first medical device, the second physiological parameter valueformatted according to a protocol not used by the first medical device,such that the first medical device is not able to process the secondphysiological parameter value to produce a displayable output value;pass the physiological parameter data from the first medical device to atranslation module; receive translated parameter data from thetranslation module at the first medical device, the translated parameterdata able to be processed for display by the first medical device; andoutput a second value from the translated parameter data for display.

The system of the preceding paragraph can be combined with anysubcombination of the following features: the first medical device canalso output the first value of the physiological parameter and thesecond value from the translated parameter data on the same display; thefirst medical device can also output the first value of thephysiological parameter and the second value from the translatedparameter data on separate displays; the first medical device can alsooutput the second value from the translated parameter data to anauxiliary device; the auxiliary device can be a television monitor; theauxiliary device can be selected from the group consisting of a tablet,a phone, a wearable computer, and a laptop; the first medical device caninclude the translation module; the first medical device can also passthe physiological parameter data to the translation module over anetwork; and the physiological parameter data can include data from aninfusion pump or a ventilator.

VI. Terminology

Many other variations than those described herein will be apparent fromthis disclosure. For example, depending on the embodiment, certain acts,events, or functions of any of the algorithms described herein can beperformed in a different sequence, can be added, merged, or left outaltogether (e.g., not all described acts or events are necessary for thepractice of the algorithms). Moreover, in certain embodiments, acts orevents can be performed concurrently, e.g., through multi-threadedprocessing, interrupt processing, or multiple processors or processorcores or on other parallel architectures, rather than sequentially. Inaddition, different tasks or processes can be performed by differentmachines and/or computing systems that can function together.

It is to be understood that not necessarily all such advantages can beachieved in accordance with any particular embodiment of the embodimentsdisclosed herein. Thus, the embodiments disclosed herein can be embodiedor carried out in a manner that achieves or optimizes one advantage orgroup of advantages as taught herein without necessarily achieving otheradvantages as may be taught or suggested herein.

The various illustrative logical blocks, modules, and algorithm stepsdescribed in connection with the embodiments disclosed herein can beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. The described functionality can be implemented invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the disclosure.

The various illustrative logical blocks and modules described inconnection with the embodiments disclosed herein can be implemented orperformed by a machine, such as a general purpose processor, a digitalsignal processor (DSP), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general purpose processor can be a microprocessor,but in the alternative, the processor can be a controller,microcontroller, or state machine, combinations of the same, or thelike. A processor can include electrical circuitry or digital logiccircuitry configured to process computer-executable instructions. Inanother embodiment, a processor includes an FPGA or other programmabledevice that performs logic operations without processingcomputer-executable instructions. A processor can also be implemented asa combination of computing devices, e.g., a combination of a DSP and amicroprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration. A computing environment can include any type of computersystem, including, but not limited to, a computer system based on amicroprocessor, a mainframe computer, a digital signal processor, aportable computing device, a device controller, or a computationalengine within an appliance, to name a few.

The steps of a method, process, or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module stored in one or more memory devices andexecuted by one or more processors, or in a combination of the two. Asoftware module can reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of non-transitory computer-readable storagemedium, media, or physical computer storage known in the art. An examplestorage medium can be coupled to the processor such that the processorcan read information from, and write information to, the storage medium.In the alternative, the storage medium can be integral to the processor.The storage medium can be volatile or nonvolatile. The processor and thestorage medium can reside in an ASIC.

Conditional language used herein, such as, among others, “can,” “might,”“may,” “e.g.,” and the like, unless specifically stated otherwise, orotherwise understood within the context as used, is generally intendedto convey that certain embodiments include, while other embodiments donot include, certain features, elements and/or states. Thus, suchconditional language is not generally intended to imply that features,elements and/or states are in any way required for one or moreembodiments or that one or more embodiments necessarily include logicfor deciding, with or without author input or prompting, whether thesefeatures, elements and/or states are included or are to be performed inany particular embodiment. The terms “comprising,” “including,”“having,” and the like are synonymous and are used inclusively, in anopen-ended fashion, and do not exclude additional elements, features,acts, operations, and so forth. Also, the term “or” is used in itsinclusive sense (and not in its exclusive sense) so that when used, forexample, to connect a list of elements, the term “or” means one, some,or all of the elements in the list. Further, the term “each,” as usedherein, in addition to having its ordinary meaning, can mean any subsetof a set of elements to which the term “each” is applied.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it will beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the spirit of the disclosure. As will berecognized, certain embodiments of the inventions described herein canbe embodied within a form that does not provide all of the features andbenefits set forth herein, as some features can be used or practicedseparately from others.

Additionally, all publications, patents, and patent applicationsmentioned in this specification are herein incorporated by reference tothe same extent as if each individual publication, patent, or patentapplication was specifically and individually indicated to beincorporated by reference.

What is claimed is:
 1. A system for providing medical data translationfor output on a medical monitoring hub, the system comprising: aportable physiological monitor comprising a processor configured to:receive a physiological signal associated with a patient from aphysiological sensor, calculate a physiological parameter based on thephysiological signal, and provide a first value of the physiologicalparameter to a monitoring hub for display; the monitoring hub comprisinga docking station configured to receive the portable physiologicalmonitor, the monitoring hub configured to: receive the first value ofthe physiological parameter from the portable physiological monitor;output the first value of the physiological parameter for display;receive physiological parameter data from a medical device other thanthe portable physiological monitor, the physiological parameter dataformatted according to a protocol other than a protocol nativelyreadable or displayable by the monitoring hub; pass the physiologicalparameter data to a translation module; receive translated parameterdata from the translation module, the translated parameter data readableand displayable by the monitoring hub; and output a second value fromthe translated parameter data for display.
 2. The system of claim 1,wherein the monitoring hub is further configured to output the firstvalue of the physiological parameter and the second value from thetranslated parameter data on separate displays.
 3. The system of claim2, wherein the monitoring hub is further configured to output the secondvalue from the translated parameter data to an auxiliary device having aseparate display from a display of the monitoring hub.
 4. The system ofclaim 3, wherein the auxiliary device is selected from the groupconsisting of a television, a tablet, a phone, a wearable computer, anda laptop.
 5. The system of claim 1, wherein the physiological parameterdata comprises data from an infusion pump.
 6. The system of claim 1,wherein the physiological parameter data comprises data from aventilator.
 7. The system of claim 1, wherein the translation module isconfigured to translate the physiological parameter data from a firstHealth Level 7 (HL7) format to a second HL7 format.
 8. A method ofproviding medical data translation for output on a medical monitoringhub, the method comprising: under the control of a first medical devicecomprising digital logic circuitry, receiving a physiological signalassociated with a patient from a physiological sensor; obtaining a firstphysiological parameter value based on the physiological signal;outputting the first physiological parameter value for display;receiving a second physiological parameter value from a second medicaldevice other than the first medical device, the second physiologicalparameter value formatted according to a protocol not used by the firstmedical device, such that the first medical device is not able toprocess the second physiological parameter value to produce adisplayable output value; passing the physiological parameter data fromthe first medical device to a separate translation module; receivingtranslated parameter data from the translation module at the firstmedical device, the translated parameter data able to be processed fordisplay by the first medical device; and outputting a second value fromthe translated parameter data for display.
 9. The method of claim 8,further comprising translating the message by at least translating themessage from a first Health Level 7 (HL7) format to a second HL7 format.10. The method of claim 8, wherein the message comprises data from aphysiological monitor.
 11. The method of claim 10, wherein the messagecomprises data from an infusion pump or a ventilator
 12. The method ofclaim 8, wherein the message comprises data from a hospital bed.
 13. Asystem for providing medical data translation for output on a medicalmonitoring hub, the system comprising: a first medical device comprisingelectronic hardware configured to: obtain a first physiologicalparameter value associated with a patient; output the firstphysiological parameter value for display; receive a secondphysiological parameter value from a second medical device other thanthe first medical device, the second physiological parameter valueformatted according to a protocol not used by the first medical device,such that the first medical device is not able to process the secondphysiological parameter value to produce a displayable output value;pass the physiological parameter data from the first medical device to atranslation module; receive translated parameter data from thetranslation module at the first medical device, the translated parameterdata able to be processed for display by the first medical device; andoutput a second value from the translated parameter data for display.14. The system of claim 13, wherein the first medical device is furtherconfigured to output the first value of the physiological parameter andthe second value from the translated parameter data on the same display.15. The system of claim 13, wherein the first medical device is furtherconfigured to output the first value of the physiological parameter andthe second value from the translated parameter data on separatedisplays.
 16. The system of claim 15, wherein the first medical deviceis further configured to output the second value from the translatedparameter data to an auxiliary device.
 17. The system of claim 16,wherein the auxiliary device is a television monitor.
 18. The system ofclaim 16, wherein the auxiliary device is selected from the groupconsisting of a tablet, a phone, a wearable computer, and a laptop. 19.The system of claim 13, wherein the first medical device comprises thetranslation module.
 20. The system of claim 13, wherein the firstmedical device is further configured to pass the physiological parameterdata to the translation module over a network.
 21. The system of claim13, wherein the physiological parameter data comprises data from aninfusion pump or a ventilator.